NIST  Special  Publication  500-206 


Computer 
I  Systems 
Technology 

U.S.  DEPARTMENT  OF 
COMMERCE 
Technology  Administration 
National  Institute  of 
Standards  and 
Technology 

Nisr 


Stable  Implementation  Agreements  for 
Open  Systems  Interconnection  Protocols 
Version  6  Edition  1 
December  1992 

Based  on  the  Proceedings  of  the  OSE  Implementors'  Workshop  (OIW) 


Workshop  Chairman/Technical  Editor 
Tim  Boland,  NIST 


Workshop  Editor 
Brenda  Gray 


NAT'L  INST.  OF  STAND  &  TECH  R.LC, 


A111D3  TSEEm 


NIST 
I  PUBLICATIONS 


PART  ONE  THROUGH  FOURTEEN 


100 
.U57 
500-205 
Pt.1 
1993 
C.2 


7 he  National  Institute  of  Standards  and  Technology  was  established  in  1988  by  Congress  to  "assist 
industry  in  the  development  of  technology  .  .  .  needed  to  improve  product  quality,  to  modernize 
manufacturing  processes,  to  ensure  product  reliability  .  .  .  and  to  facilitate  rapid  commercialization  ...  of 
products  based  on  new  scientific  discoveries." 

NIST,  originally  founded  as  the  National  Bureau  of  Standards  in  1901,  works  to  strengthen  U.S. 
industry's  competitiveness;  advance  science  and  engineering;  and  improve  public  health,  safety,  and  the 
environment.  One  of  the  agency's  basic  functions  is  to  develop,  maintain,  and  retain  custody  of  the  national 
standards  of  measurement,  and  provide  the  means  and  methods  for  comparing  standards  used  in  science, 
engineering,  manufacturing,  commerce,  industry,  and  education  with  the  standards  adopted  or  recognized 
by  the  Federal  Government. 

As  an  agency  of  the  U.S.  Commerce  Department's  Technology  Administration,  NIST  conducts  basic 
and  applied  research  in  the  physical  sciences  and  engineering  and  performs  related  services.  The  Institute 
does  generic  and  precompetitive  work  on  new  and  advanced  technologies.  NIST's  research  facilities  are 
located  at  Gaithersburg,  MD  20899,  and  at  Boulder,  CO  80303.  Major  technical  operating  units  and  their 
principal  activities  are  listed  below.  For  more  information  contact  the  Public  Inquiries  Desk,  301-975-3058. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Chair  of  the  Open  Systems 
Environment  Implementors'  Workshop  (OIW). 

This  part  replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change 
from  this  text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  1  -  General  Information 


0  Introduction 

This  document  records  current  stable  implenientation  agreements  of  OSI  protocols  among  the  organizations 
participating  in  the  Open  Systems  Environment  Impiementors'  Workshop  (OIW).  Statsle  in  the  context  of 
this  document  means  the  following: 

a)  the  agreements  are  based  on  final  standards  (e.g.,  ISO-iS  or  CCITT  Recommendations)  or  nearly 
final  (e.g.,  ISO-DIS)  with  no  significant  changes  expected; 

b)  the  agreements  have  been  approved  by  the  OSE  Impiementors'  Workshop  (OIW)  Plenary  for 
progression  from  the  Working  Agreements  document  to  this  document  after  a  period  of  review. 
These  agreements  are  considered  final;  the  only  changes  allowed  will  be  clarifications,  and  certain 
Technical  and  Alignment  errata.  These  changes  must  have  the  strong  support  of  vendors,  and  be 
justifiable. 

For  these  reasons,  the  agreements  are  considered  advanced  enough  for  use  in  product  and  test  suite 
development.  This  means  that  readers  can  use  this  text  as  a  Isasis  for  procurement  references  for  OSI 
products.  All  of  the  text  in  this  document  is  considered  stable  as  defined  above. 

Future  releases  of  these  Stable  Agreements  will  add  and/or  extend  functionality  offered  by  this  edition  and 
versk>n.  When  required,  new  versions  will  be  introduced  on  a  yearly  basis.  It  is  the  OSE  impiementors' 
Workshop  (OIW)  intent  that  new  versions  of  this  Stat>le  Agreements  document  will  be  compatible  with  the 
present  version.  If  this  proves  impractical,  the  agreements  will  attempt  to  provide  mechanisms  and 
gukJelines  which  maximize  Interoperability.  Furthermore,  it  is  the  intent  that  these  stat)ie  agreements  be 
maintained  via  the  Errata  process  as  long  as  is  appropriate.  For  the  subject  area,  interworking  information 
and  other  useful  advice  to  the  reader  is  given  as  appropriate.  Specific  "defect  report"  information  (including 
extent  erf  applicability)  is  provided  in  designated  portions  of  each  Part. 


1  Scope 

Agreements  text  is  either  in  this  Stable  Document  (Stable)  or  in  the  aligned  Working  Document  (not  yet 
stable).  It  is  a  goal  that  the  same  text  not  appear  in  the  same  position  in  both  documents  at  once  (except 
for  part  1).  Modifications  to  a  version  reflect  very  recent  stable  functionality  as  well  as  editorial,  technical, 
and  alignment  errata,  all  applied  to  the  previous  edition. 

The  intended  audience  for  this  document  is  composed  of  those  indivkJuals  who  are  interested  in  Stable 
Implementation  Agreements  for  OSI  protocols.  Each  part  of  the  document  covers  a  different  subject  area, 
and  the  parts  are  presented  so  as  to  present  a  consistent  and  unified  approach.  The  format  of  this  version 
follows  the  ISO  directives  whenever  possible. 

The  corresponding  and  aligned  document,  "Wori<ing  Implementation  Agreements  for  OSI  Protocols,"  records 
agreements  which  are  not  yet  conskJered  stable,  in  the  sense  described  above.  This  document  will  be 
referenced  as  the  'Wori<ing  Agreements  Document."  This  Stable  document  is  aligned  with  the  Wori<ing 
Agreements  Document  in  the  sense  that  the  structures  are  identical,  and  pointers  are  given  in  this  Stable 
Document  to  work  in  the  Working  Agreements  Document  which  could  become  statsle  in  the  future. 
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The  benefit  of  this  document  to  the  reader  is  that  it  gives  a  complete  accounting  of  current  stable 
agreements.  Minor  changes  (Errata)  to  these  agreements  will  be  issued  in  replacement  page  format.  These 
errata  will  only  be  applied  to  the  current  version. 

Currently  efforts  are  under  way  to  define  worldwide  technically  harmonized  profiles.  The  goal  is  to  create 
a  consolidated  global  market  for  OSI  products.  This  means  that  vendors  can  sell  to  a  larger  market,  and 
users  can  procure  products  from  a  variety  of  vendors  around  the  world.  Agreements  in  this  document  are 
likely  to  be  used  in  these  alignment  efforts. 

This  version  is  backwards  compatible  with  the  previous  version  to  the  maximum  extent  possible.  This 
version  includes  all  of  the  material  from  the  previous  version  (modified  by  errata)  as  well  as  new  stable 
material  from  the  previous  year. 


2     Normative  References 

See  succeeding  parts. 


3  Definitions 

See  succeeding  parts. 


4     Purpose  of  the  Workshop 

In  February,  1983,  at  the  request  of  industry,  NIST  organized  the  OSI  Implementors'  Workshop  (OIW)  for 
Implementors  of  OSI  to  bring  together  future  users  and  potential  suppliers  of  OSI  protocols.  The  Workshop 
accepts  as  input  the  specifications  of  emerging  standards  for  protocols  and  produces  as  output  agreements 
on  the  implementation  and  testing  particulars  of  these  protocols.  This  process  is  expected  to  expedite  the 
development  of  OSI  and  OSE  protocols  and  promote  interoperability  of  independently  manufactured  data 
communications  equipment.  Recently  the  Workshop  was  renamed  the  Open  Systems  Environment 
Implementors'  Workshop  (OIW). 
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5    Workshop  Organization 

The  Workshop  organizes  Its  work  through  Special  Interest  Groups  (SIGs)  that  prepare  technteai 
documentatton.  An  executive  committee  of  SIG  chairpersons  led  by  the  overall  Workshop  chairperson 
administers  the  Workshop.  NiST  Invites  hIgNy  qualified  technical  leaders  from  participating  organizations 
to  assume  leadership  roles  In  tfie  SIGs.  The  SIGs  are  encouraged  to  coordinate  with  standards 
organizatk>ns  and  user  groups,  and  to  seek  wkiespread  technical  consensus  on  implementation  agreenrtents 
through  Intemattonal  discussions  and  liaison  activities. 

The  Workshop  meets  four  times  a  year  at  the  National  Institute  of  Standards  and  Technology  in 
Galthersburg,  Maryland  where  each  SIG  Is  required  to  convene  its  meeting.  In  addition,  a  plenary  assembly 
of  all  Workshop  delegates  is  convened  for  consideration  of  SIG  motions  and  other  Workshop  business. 
SIGs  are  also  erKXHjraged  to  hold  interim  meetings  at  varied  locations  around  the  world. 

The  Workshop  is  an  open  public  forum.  Registration  materials,  documents,  and  Workshop  schedules  are 
available  from: 

Natk>nal  Institute  of  Standards  and  Technology 
OSE  Impiementors'  Workshop  (OIW) 
Bunding  225.  Room  B-217 
Galthersburg,  Maryland  20899 


6    Use  and  Endorsement  by  otiier  Enterprises 

The  Workshops  are  held  for  those  organizations  expressing  an  interest  in  implementing  or  procuring  OSI 
Protocols  and  Open  Systems.  However,  there  is  no  corporate  commitment  to  implementations  associated 
with  Workshop  participation. 

The  Workshop  and  associated  agreements  have  been  endorsed  by  various  activities  and  groups.  See  the 
aligned  clause  of  the  Working  Agreements  Document  for  more  on  this  subject. 


7    Relationsllip  of  the  Worlcshop  to  the  NIST 

As  resources  permit,  NIST,  with  voluntary  assistance  from  industry,  develops  formal  protocol  specifications, 
reference  Implementations,  tests,  and  test  systems  for  the  protocols  agreed  to  In  the  Workshops.  The  NiST 
organizes,  administers,  and  makes  technical  contributions  to  the  Workshop.  The  NiST  bears  no  other 
relatk>n  to  the  workshop. 
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8    Structure  and  Operation  of  Workshop 


8.1  Plenary 

The  main  body  of  the  workshop  is  a  Plenary  Assembly.  Any  organization  may  participate.  Representation 
is  International.  The  NiST  prefers  for  the  business  of  Workshops  to  be  conducted  Informally  since  there  are 
no  corresponding  forma!  commitments  within  the  Workshop  to  implement  the  decisions  reached.  For  more 
informatkNi,  consult  the  aligned  clause  of  the  Working  Agreements  Document. 


8.2     Special  Interest  Groups 

Within  the  Workshop  there  are  Special  Interest  Groups  (SIGs).  The  SIGs  receive  their  Instructtons  for  tfieir 
technk:al  program  of  work  from  the  Plenary.  The  SIGs  meet  independently  during  the  WorksfK>p  week.  As 
techntoal  work  is  completed  by  a  SiG,  It  is  presented  to  the  Plenary  for  disposltton.  For  more  informatton 
on  SIGs  (including  SIG  charters),  consult  the  aligned  clause  of  the  Working  Agreements  Docunwnt. 


9    Points  of  Contact 

For  informatk>n  concerning  the  workshop,  write  to: 

Chair.  OSE  Implementors'  Workshop  (OIW),  at  the  address  given  in  1.3. 

IndMdual  points  of  contact  are  given  in  the  aligned  part  of  the  Working  Agreements  Document 


10  Profile  Conformance 

NOTE  •  SIG  text  relating  to  text  below  may  be  given  in  some  succeeding  parts. 

This  clause  presents  general  concepts  for  profile  confomiance.  These  concepts  shall  be  observed  when 
writing  Implementation  Agreements. 


10.1    General  Principle 

Conformance  to  an  OSI  Profile  (Implementatton  Agreements.  Functional  Standards)  implies  conformance 
to  the  referenced  Base  Standards. 

Therefore,  a  Profile  shall  not  specify  any  requirements  that  would  contradk^  or  cause  non-conformance  to 
the  Base  Standards  to  which  it  refers  (see  TR  10000-1.  clauses  6.1. 6.3.1).  The  conformance  requirements 
defined  in  ISO/IEC  TR  10000-1  fully  apply. 
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10.2  Constraints 

Base  standards  usually  provide  options  for  PDUs.  parameters,  encoding  choices,  value  ranges,  etc. 

A  profile  may  make  specific  choices  of  these  options  and  ranges  of  values.  For  the  promotion  of 
Interoperability,  pragmatic  constraints  or  minimum  requirements  may  be  Imposed  (e.g..  the  limitation  of 
Search  operations,  selection  of  encoding  choices,  value  ranges,  byte  ranges  for  encoding).  These  minimum 
requirements  of  restrictions  shall  not  contradict  the  conformance  requirements  of  the  respective  base 
standards. 


10.2.1      Sending/Encoding  Entity 

In  order  to  promote  inten/vorking.  reasonable  restrictions  or  minimum  requirements  may  t>e  SF>ecified  In  a 
profile  as  described  above. 


10.2.2     Receiving/Decoding  Entity 

Minimum  requirements  of  receiving/decoding  capability  for  alternatives,  permissible  values,  etc.  may  be 
specified  in  a  profile.  A  profile  shall  not  specify  the  behavior  of  a  receiving/decoding  entity  when  receiving 
data  which  Is  outside  the  scope  of  or  excluded  by  the  Profile  for  senders. 

A  Profile  Conformance  Test  shall  be  limited  by  the  scope  of  the  profile  specification  and  shall  not  probe 
beyorxJ  its  boundaries.  That  means,  the  capability  of  a  receiver/decoder  would  be  tested  only  in  the  range 
of  choices  or  values  which  are  specified  for  the  sending/encoding  entity  (i.e..  for  interworking  between 
systems  both  being  conformant  to  the  Profiles). 


10.3    Classification  of  Conformance 

Conformance  requirements  of  a  profile  shall  be  related  to  conformance  requirements  of  a  base  standard  as 
written  in  clause  6.5  and  annnex  C  of  ISO/IEC  TR  10000-1.  For  the  conformance  classes,  the  following 
terminology  shall  be  used  unless  otherwise  specified  by  the  base  standard  or  equivalent  conformance 
requirements  for  a  profile  as  required  by  the  ISO/IEC  Technical  Committee  that  is  responsible  for  the  base 
standard: 


a) 

m 

mandatory; 

b) 

0 

optional: 

c) 

c 

conditional; 

d) 

X 

excluded; 

e) 

i 

out  of  scope; 
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Foreword 

This  part  of  the  Stat>le  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  Open  Systems  Environment  Implementors'  Worl<shop  (OIW).  See  Procedures  Manual  for 
Woricshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject. 

Annexes  A  and  B  are  for  information  only. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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0  Introduction 

This  part  provides  agreements  about  sukKietwortc  services  used  in  support  of  the  OSi  Network  L^yer. 


1  Scope 

These  agreements  cover  sutMietworIc  types  including  locai  area  networks,  packet  switched  networks,  circuit 
switched  networks.  iSDN.  and  others. 


2    Normative  References 


2.1  CCITT 

[1]      Recommendation  i.231  (Biue  Book,  1988).  Circuit-Mode  Bearer  Service  Categories. 

[2]      Recommendation  1.232  (Blue  Book,  1988).  Pacliet-Mode  Bearer  Service  Categories. 

[3]  Recommendation  1.431  (Blue  Book,  1988),  Primary  Rate  User-Networii  interface  -  iotyer  1 
Specification. 

[4]  Recommendation  Q.921  (1.441)  (Blue  Book,  1988),  ISDN  User-Networl(  interface,  Data  Linl(  Layer 
Specification. 

[5]  CCITT  Recommendation  Q.922,  iSDN  Data  Unit  L^yer  Specification  for  Frame  Mode  Bearer 
Sen/ices,  iTU,  Geneva,  (1991). 

[6]  Recommendatton  Q.931  (1.451)  (Blue  Book.  1988).  ISDN  User-Networl(  Interface  Layer  3 
Specification  for  Basic  Call  Control. 

[T]  CCITT  Recommendation  Q.933.  ISDN  Signaling  Specmcation  for  Frame  Mode  Bearer  Sen/ices.  ITU. 
Geneva  (1992). 

[8]  Recommendation  X.25  (Yellow  Book  1980).  Interface  Between  Data  Terminal  Equipment  (DTE)  and 
DaUt  Circuit  Terminating  Equipment  (DCE)  for  Tenninals  Operating  in  the  Paci<et  Mode  on  Public 
Data  Networl(s. 

[9]  Recommendation  X.25  (Blue  Book.  1988).  Interface  Between  Data  Terminal  Equipment  (DTE)  and 
Data  Circuit-Terminating  Equipment  (DCE)  for  Terminals  Operating  in  the  Paciiet  Mode  and 
Connected  to  Public  Data  Networks  by  Dedicated  Circuit. 

[10]     Recommendation  X.31  (BlueBook.  ^988),  Support  of  Packet  Mode  Tenninai  Equipment  by  an  ISDN. 
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2.2  ISO 

[11]     ISO  7776.  Information  processing  systems  -  Dam  communication  -  Higti-level  Dam  Link  ConUol 
Procedures  -  Description  of  the  X.25  LAPB-compatibie  DTE  dam  link  procedures. 

[12]     ISO/IEC  8208  Edition  2,  Information  technology  -  Data  communications  -  X.25  Packet  layer  protocol 
for  dam  terminal  equipment. 

[13]     ISO  8802-2,  Information  processing  systems  -  Local  area  networks  -  Part  2:  Logical  link  control. 

[14]     ISO  DIS  8802-3,  Information  processing  systems  -  Local  area  networks  -  Part  3:  Carrier  sense 
multiple  access  method  with  collision  detection  (CSMA/CD)  and  physical  layer  specifications. 

[15]     ISO  DIS  8802-4,  information  processing  systems  -  Local  area  networks  -  Part  4:  Token-passing  bus 
access  method  and  physical  layer  specifications. 

[16]     ISO  8802-5,  Information  processing  systems  -  Local  area  networks  -  Part  5:  Token  ring  access 
method  and  physical  layer  specifications. 

[20]     ISO  10039,  information  Technology  -  Local  Area  Networks  -  MAC  Service  Definition 


2.3  ANSI 

[21]     ANSI/IEEE  802.2.  Logical  Link  Control,  1987. 

[22]     ANSI/IEEE  802.3.  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD)  and  Physical 
Layer  Specifications,  1985. 

[23]     ANSI/IEEE802.3Supplementa,MAC/anc/8ase5anc/Meof/t;mSpec/f/caf/oa  Type  10BASE2 (Section 
10),  1988. 

[24]     ANSI/IEEE  802.3  Supplement  b.  Broadband  MAU  and  Broadband  Medium  Specifications,  Type 
10BROAD36  (Section  11),  1988. 

[25]     ANSI/IEEE  802.3  Supplement  c.  Repeater  Unit  for  10  Mb/s  Baseband  Networks  (Section  9),  1988. 

[26]     ANSI/IEEE  802.3  Supplement  e,  Physical  Signaling,  Medium  Attachment,  and  Baseband  Medium 
Specifications,  Type  1  BASES  (Section  12),  1988. 

[27]     ANSI/IEEE  802.4.  Token-Passing  Bus  Access  Method  and  Physical  Layer  Specifications,  Draft 
1987. 

[28]     ANSI/IEEE  802.5.  Token-Ring  Access  Method  and  Physical  Layer  Specifications,  1986. 

[29]     ANS  T1 .408-1 990.  ISDN  Primary  Interface  -  Customer  Installation  Metallic  Interfaces  -  Layer  1 
Specification. 
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[30]     ANS  T1.601,  Integrated  Services  Digital  Network  (ISDN)  -  Basic  Access  Interface  for  Use  on 
Metallic  Loops  for  Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification). 

[31  ]     ANS  T1 .602,  Integrated  Sen/ices  Digital  Network  (ISDN)  -  Data-Link  Layer  Signalling  Specification 
for  Application  at  the  User-Network  Interface. 

[32]     ANS  T1.605,  Integrated  Sen/ices  Digital  Network  (ISDN)  -  Basic  Access  Interface  for  S  and  T 
Reference  Points  -  Layer  1  Specification. 

[33]     ANS  T1 .606  -  Frame  Relay  Bearer  Sen/ice  -  Architectural  Framework  and  Service  Description,  1 990. 

[34]     ANS  T1 .606  -  Addendum  1  -  Frame  Relaying  Bearer  Sen/ice  -  Architectural  Framework  and  Service 
Description.  (Final  text  may  be  found  in  T1S1  /91-454.) 

[35]     ANS  T1.607,  Telecommunications  •  Digital  Subscriber  Signaling  System  #7  -  Layer  3  Signaling 
Specification  for  Circuit  Switched  Bearer  Sen/ice. 

[36]     ANS  T1.608,  Telecommunications  -  Digital  Subscriber  Signaling  System  #r  -  Layer  3  Signaling 
Specification  for  Packet  Switched  Bearer  Sen/ice. 

[37]     ANS  T1 .61 7  -  DSSI  -Core  Aspects  of  Frame  Protocol  for  Use  with  Frame  Relay  Bearer  Se/v/ce,  1 991 . 

[38]     ANS  T1 .61 8  -  DSSI  -Signaling  Specification  for  Frame  Relay  Bearer  Sen/ice,  1 991 . 

[39]     ANS  X3. 1 39,  Fiber  distributed  data  interface  (FDDI)  -  Token  ring  media  access  control  (MAC) ,  1 987. 

[40]     AHSX3.A  48.  Fiber  distributed  data  interface  (FDDI)  -  Token  ring  physical  layer  protocol  (PHY),  1988. 

[41]     ANS  X3.166,  Fiber  distributed  data  interface  (FDDI)  -  Physical  layer  medium  dependent  (PMD), 
1989. 

3  Status 

This  version  was  completed  in  December  1990. 
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4  Errata 

NOTE  -  This  dause  may  contain  "defect  report"  and  resoiutions  material,  and  the  versiona  of  Imptementor's 
Agreeni«nt8  to  which  this  material  applies. 

5  Local  Area  Networks 

5.1      IEEE  802.2  Logical  Link  Control 

The  following  decisions  have  Iseen  reached  with  respect  to  this  protocol: 

a)  Uvk  Service  Access  Point  (LSAP): 

1)  The  code  below  shall  be  used  to  address  systems  using  Network  Layer  protocols 
identified  by  ISO  TR  9577  (e.g..  ISO  8473.  ISO  8208).  Note  that  bit  zero  is  transmitted  first; 

2)  The  nu>st  significant  bit  is  bit  7.  thus  this  bit  pattern  represents  he)(adecimal  FE  (see 
figure  1  below); 

b)  Type  and  Class: 

1)  Only  the  connectionless  type  1,  dass  I  IEEE  802  link  service  wHi  be  used. 


Figure  1  -  LSAP  bit  pattern 


5.2     IEEE  802.3  CSMA/CD  Access  Method 

The  following  implementation  agreements  have  been  reached  with  respect  to  the  IEEE  802.3  CSMA/CO 
Access  Method  and  Physical  Layer  Specifications: 

a)  The  address  length  shall  be  48  bits; 

b)  For  a  data  packet  of  LLC  data  length  of  n  octets,  the  length  of  the  pad  fiekJ  is  as  follows: 

1)  max(0.  minFrameSize-(8n-i-2(addressSize)-(-48))  bits. 
The  following  implementation  agreements  have  been  reached  with  respect  to  10  BROAD  36  Networks: 
a)  Sin^e  Cable  Networks: 

1)  The  translator  frequency  shall  be  192.25  Mhz; 
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2)  The  channel  allocations  are  as  follows: 

a)  Reverse  Channels: 

1)  T12.  T13.  T14 

2)  T13.  T14.  2' 

3)  T14,  2'.  3' 

4)  2'.  3'.  4' 

5)  3'.  4'.  4A' 

6)  4',  4A'.  5' 

b)  Forward  Channels: 

1)  UM.N 

2)  M.  N.  O 

3)  N.O.P 

4)  O.  P.  Q 

5)  P.Q.R 

6)  Q.R.S 
b)  Dual  Cable  Networks: 

For  nontranslated  dual  cable  networks  forward  and  reverse  frequencies  are  the  sanie.  Permissible 
channel  allocations  are  listed  below: 

1)  T12.T13.T14 

2)  T13.T14.  2* 

3)  T14.  2'.  3* 

4)  2'.  3*.  4* 

5)  3'.  4'.  4A' 

6)  4'.  4A'.  5' 

7)  L.M.  N 
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8)  M.  N.  O 

9)  N.  O.  P 

10)  O,  P.  Q 

11)  Q.  R.  S 

c)  When  both  IEEE  802.4  and  IEEE  802.3  10  BROAD  36  networks  coexist  on  the  broadband  cable 
system  the  preferred  channel  allocations  are  as  follows: 

1)  Reverse: 

a)  T12.  T13.  T14  -  IEEE  802.3; 

b)  6'.  FM1'- IEEE  802.4; 

c)  3',  A'-  Channels  reserved  for  future  use; 

d)  4A',  5'  -  Channels  reserved  for  future  use; 

2)  Forward: 

a)  L,  M,  N  -  IEEE  802.3; 

b)  T.  U  -  IEEE  802.4; 

c)  P,  Q  -  Channels  reserved  for  future  use; 

d)  R,  S  -  Channels  reserved  for  future  use. 

The  following  implementation  agreements  have  been  reached  with  respect  to  10  BASE-T  networks: 

a)  Auto-partition:  A  repeater  port  which  connects  10  BASE-T  links  either  through  an  external  or 
internal  MAU  shall  implement  the  auto-partition  and  reconnections  algorithm  as  defined  In  IEEE 
802.3,  Chapter  9. 

5.3      IEEE  802.4  Token  Bus  Access  Method 

The  following  options  are  agreed  to  with  respect  to  Draft  J  of  token  bus: 

a)  Data  Rate: 

1)  10  Mb  (Broadband); 

2)  5  Mb  (Carrierband); 

b)  Addressing:  48  bit; 
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c)  The  ImeOption.  Priority  Mechanism,  shaii  be  implemented; 

d)  Broadband  Channel  Assignments  are  as  follows: 

1)  Forward: 

a)  P 

b)  Q 

c)  R 

d)  S 

e)  T 

f)  U 

2)  Reverse: 

a)  3' 

b)  A' 

c)  4A' 

d)  5' 

e)  6' 

f)  FM1'. 

5.4      IEEE  802.5  Token  Ring  Access  Method 

The  following  Implementation  agreements  have  been  reached  with  respect  to  the  IEEE  Standard  802.5. 
Token  Passing  Ring  Access  Method  and  Physical  Layer  specification: 

a)  The  data  signalling  rate  shall  be  4  Mblt/s; 

b)  The  address  length  shall  be  48  bits; 

c)  The  message  priority  (PM)  of  the  AMP  data  unit  shall  be  7; 

d)  The  ALL_STATIONS_THIS_RING_ADDRESS  shall  be  X'COOOFFFFFFFF'; 

e)  The  TRR  value  shall  be  4  milliseconds; 

f)  The  THT  value  shall  be  8.9  milliseconds; 
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g)  The  TQP  value  shall  be  20  milliseconds: 

h)  The  TVX  value  shall  be  10  milliseconds; 

i)  The  TNT  value  shall  be  2.6  milliseconds; 
])  The  TAM  value  shall  be  7  seconds; 

k)  The  TSM  value  shall  be  15  seconds; 

I)  The  MAC  Infomnation  field  (l-fieid)  shall  be  defined  as  follows  in  figure  2  below.  Sequences  are 
as  follows: 

1)  Starting  Sequence  includes:  SD.  AC.  FC,  DA.  SA; 

2)  Ending  Sequence  includes:  PCS.  ED,  FS; 

m)  With  the  above  timer  and  MAC  l-field  definitions,  the  following  limits  are  defined: 

1)  Protocol  limits  the  l-field  to  a  maximum  of  4425  bytes; 

2)  All  stations  shall  support  l-fields  that  have  a  minimum  of  one  byte  and  a  maximum  of 
at  least  2000  bytes. 


Starting  Sequence 


I-Field 


End  Sequence 


Figure  2  -  l-FiekJ  format 

AH  Vt3im  rin0  Heroes  ^ouid  «U{>i)Ottlli«  use  d^oi^  MAO  ii:l!!:l^ri0  0ti  ^Kfc^^ii^^^iipl 
9/ifke$^n0  In  accordance  vi^  ISO  B$02^>  tt   $lrortgiy  recommencled  M  Qroup  9<;ldl^i^i^ipli^i| 

HOTS  •  )ti»«9$p^$d  it^it^ppott  k>r group  MAC actdr^rtfii  lor  OSI  u$8g»«h4ito»«rianaafoty|^  ii»<Utu^ 

OKtQting  txmM  ^t«m$      hava  gmitedy  <^  n4  ^Wfy  to  suppoit        ^isi^mi$^.  Betor  to  nm 


5.5      Fiber  Distributed  Data  Interface  (FDDI) 
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5.5.1       Token  Ring  Media  Access  Control  (MAC,  X3.139-1987) 

The  following  are  Implementation  agreements  with  respect  to  FDOl  MAC: 

a)  The  address  length  shall  be  48  bits; 

b)  There  shall  be  some  manual  or  programmatic  means  of  resetting  stations  arxJ  concentrators  to 
the  values  specified  as  defaults  herein  or  in  X3. 139-1 987; 

c)  The  default  value  of  T_Max  shall  be  at  least  165  millisecorKis  and  not  more  than  200 
milliseconds; 

d)  The  default  value  of  T_Req  shall  be  equal  to  T_MAX_LB.^ ; 

e)  All  FDDI  stations  shall  process  lnfo_Fields  of  0  to  4478  bytes.  The  frame  is  defined  below  in 
Figure  3; 

f)  Stations  shall  not  use  restricted  token  service. 


1  so 

PC 

DA 

SA  1 

Info 


FDDI  frame  format 


SO 
FC 
DA: 
SA 


Figure  3  - 


Preamble 

- 16  Idle  Symbols  for  Transmitting 

-  >  =  12  Idle  Symbols  for  Copying 

-  >  =  2  Idle  Symbols  for  Repeating 
Starting  Delimiter  (2  Symbols,  JK) 
Frame  Control  (2  Symbols) 
Destination  Address  (12  Symt>ols) 
Source  Address  (12  Symbols) 

INFO:  Infomnation  Field  (=  <8956  Symbols) 
FCS:    Frame  Check  Sequence  (8  Symbols) 
ED:      Ending  Delimiter  (1  Symbol) 
FS:      Frame  Status  (3  Symbols) 


5.5.2       Token  Ring  Physical  Layer  (PHY,  X3.148-1988) 

The  following  implementation  agreement  is  with  respect  to  the  FDDI  PHY  specificatk>ns: 

1  The  average  delay,  that  is  the  time  between  wfien  a  statbn  receives  a  Starting  Delimiter  (JK  symbol 
pair)  beginning  a  valid  frame  until  it  repeats  that  Starting  Delimiter,  when  that  Starting  Delimiter  is 
preceded  by  a  sequence  of  a  vaiki  frame  followed  by  50  Idle  Symbols  shall  not  exceed: 

1  microsecond  in  a  station,  and 
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1  microsecond  times  the  number  of  ports  in  a  concentrator,  in  addition  to  the  delays 
contributed  by  the  active  slaves  of  the  concentrator. 

The  measurement  method  described  above  allows  a  consistent  repeatable  measurement,  however 
it  does  not  measure  maximum  possible  delay.  When  the  delay  is  one  microsecond  as  measured 
above,  the  maximum  effective  delay  contribution  component  which  can  result  is  1.164 
microseconds.  This  number,  not  one  microsecond,  should  be  used  per  PHY  to  compute  maximum 
possible  network  delay. 


5.5.3       Physical  Layer  Media  Dependent  (PMD,  X3.1 66-1 989) 

The  following  implementation  agreements  are  with  respect  to  the  FDDI  PMD  specification: 

1  Stations  shall  repeat  all  valid  packets  under  ail  signal  conditions  specified  in  section  5.2  of  X3.166- 
1989.  "Active  Input  Interface",  with  a  bit  error  rate  (BER)  of  not  more  than  2.5  x  10'^°; 

2  Stations  shall  repeat  all  valid  packets  under  all  signal  conditions  specified  in  section  5.2,  "Active 
Input  interface",  except  that  the  Minimum  Average  Power  shall  be  -29  dBm  (2  dS  above  the 
specified  minimum),  with  a  BER  of  not  more  than  10"^^ 


6    Wide  Area  Networks 


6.1      CCITT  Recommendation  X.25 

The  procedures  required  to  describe  the  DTE  side  of  a  DTE/DCE  interface  for  systems  attached  to  sub- 
networks provkJing  an  X.25  interface  shall  be  as  defined  in  ISO  7776  and  ISO  8208  and  as  supplemented 
below.  (These  procedures  shall  also  apply  to  a  DTE  operating  on  a  DTE/DTE  interface.) 


6.2      ISO  7776 

ISO  7776  is  used  as  the  Layer  2  Protocol  with  the  agreements  defined  below: 

a)  Address  assignment  information  is  as  follows: 

1)  DTE  =  A  (=11000000  binary); 

2)  DOE  =  B  (=10000000  binary); 

3)  On  a  DTE/DTE  interface,  one  of  the  DTEs,  by  a  prior  agreement,  shall  use  the  DOE 
address; 

b)  The  modulus  shall  be  8; 

c)  A  window  size  (k)  of  7  shall  be  supported.  In  addition,  other  window  sizes  may  also  be 
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6.3      ISO  8208 

The  elements  of  ISO  8208  applicable  for  use  deperxi  on  the  OSI  role  of  ISO  8208  (I.e..  provision  of  CONS, 
support  of  Independent  of  the  role,  ISO  8208  is  used  as  the  Layer  3  protocol,  with  the  following 

agreements: 

a)  Virtual  Call  Service; 

b)  Any  mutually  agreed  window  and  pacl<et  size,  however,  all  DTEs  must  be  capable  of  supporting 
a  window  size  of  2,  a  pacl<et  size  of  128  octets,  and  a  sequence  number  modulus  of  8; 

c)  A  DTE  must  t>e  capable  of  receiving  the  Row  Control  Parameter  Negotiation  Facility  and 
responding  appropriately  (per  ISO  8208); 

d)  The  Basic  RPOA  Selection  Facility  shall  be  implemented  and  its  use  or  non-use  selectable  on 
a  per  virtual  call  basis. 

When  ISO  8208  is  used  to  support  CONS,  the  optional  user  facilities  in  Qause  5.1  of  ISO  8878  shall  also 
be  supported. 

When  ISO  8208  is  used  to  support  CLNP  (when  providing  the  CLNS),  Permanent  Virtual  Circuit  Service  may 
also  be  used. 


7    Integrated  Services  Digital  Networks  (ISDN) 


7.1  Introduction 

This  clause  defines  Implementation  Agreements  for  pacl<et-data  transfer  in  an  ISDN  context.  The  agreements 
provide  a  set  of  procedures  for  accessing  an  ISDN  so  that  end  systems  implemented  according  to  these 
agreements  can  obtain  ISDN  services  and  can  successfully  interoperate. 

The  agreements  are  not  meant  to  preclude  vendors  from  implementing  additional  procedures  as  long  as 
they  do  not  create  system  interoperability  problems.  Capabilities  will  vary  from  ISDN  to  ISDN  and 
procedures  beyond  those  included  here  may  be  necessary  to  request  and  utilize  network  services  more 
effectively  and  fully. 

The  agreements  cover  two  fundamental  ISDN  services  for  X.25  packet  mode  ISDN  terminals,  namely, 

CASE  I:  The  ISDN  provides  a  circuit-mode  (Layer  1)  connection  either  on  demand  ("switched")  or 

permanently  fdedicated  circuit").  A  general  description  of  the  con-esponding  ISDN  64  Kbps 
circuit-mode  bearer  service  is  described  in  CCITT  Recommendation  1.231 .  The  circuit-mode 
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connection  is  between  an  X.25  ISDN  terminai  and  (i)  a  PSPDN.  or  (ii)  another  X.25  iSDN 
tenninal.  The  circuit-mode  connection  to  a  PSPDN  corresponds  to  CASE  A  of  CX^iTT 
Recommendation  X.31. 

CASE  II:  The  ISDN  provides  the  X.25  virtual  circuit  service.  A  general  description  of  this  service  is 
given  In  CCITT  Recommendation  1.232.  This  case  corresponds  to  CASE  B  of  CCITT 
Recommerxiation  X.31. 

Figures  4  and  5  give  the  agreed  staclcs  for  X.25  packet  transfer  over  D  and  B  channels,  respectively.  Some 
particular  aspects  are  given  below: 

a)  The  packet  data  transfer  is  on  a  B  channel  of  a  Basic  Access  or  a  Primary  Rate  Interfece.  In 
CASE  II.  It  can  be  on  a  D  channel  of  a  Baste  Access  Intertece; 

b)  The  layer  2  procedures  are  LAPB  (ISO  7776)  on  a  B  channel  and  LAPD  (CCITT 
Recommeixlatkxi  Q.921)  on  a  D  channel; 

c)  X.25  PLP  (ISO  8208)  procedures  are  used,  including  the  setting  up  and  clearing  of  virtual  calls; 

J  d)  Q.921  wnti  Q.931  procedures  on  a  D  channel  are  used  for  access  signaling,  when  appropriate, 
to  select  the  B  or  D  channel  for  packet  data  transfer  and  for  establishing  and  releasing  a  physical 
path  In  the  ISDN; 

e)  Refer  to  part  3  for  the  specification  of  methods  for  providing  OSi  Network  Services. 


7.2     Implementation  Agreements 

This  clause  gives  Implementation  Agreements  for  individual  ISDN-related  protocols.  The  relevant  protocol 
stacks  are  given  In  figures  4  and  5. 
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OSI  LAYER 


3 

0.931 

ISO  8208 

(1.451) 

(X.25  PLP) 

2 

Q.921 

(1.441) 

(LAPD) 

1 

Hi 

D  CHANNEL 

1 

ANS  Tl. 601-1988, 

ANS  Tl. 605-1988 

ADDITIONAL  SIGNALING  PACKET  SWITCHED 

FOR  INCOMING  PACKET*      SIGNALING  AND  INFORMATION 
CALLS  TRANSFER 

*  MAY  BE  NULL 

Figure  4  -  Protocol  Layers  at  S,  T  and  U  reference  points  when  D  Channel  is  used  in  ISDN 


13 


Part  2  -  Subnetworks 


September  1992  (Stable) 


OSI  LAYER 


0.931 
(1.451) 

ISO  8208 
(X.25  PLP) 

0.921 
(LAPD) 

ISO  7776 
(X.25  LAPB) 

D  CHANNEL 


B  CHANNEL 


ANS  Tl. 601-1988,  ANS  Tl. 605-1988 
and  for  Primary  Rate  ANS  Tl. 408-1990 


J 


Note  1  Note  2 

Figure  5  -  Protocol  Layers  at  S,  T  and  U  reference  points  when  B  Channel  is  used  in  ISDN 

NOTES 

1  This  refers  to  signaling  for  drcuit  svwtched  access  (may  be  null),  as  well  as  additional  sign 
packet  calls  (may  be  null). 

2  This  refers  to  packet  switched  signaling  and  information  transfer. 

7.2.1  Physical  Layer,  Basic  Access  at  "U" 

ANS  T1 .601  -1988,  "Integrated  Services  Digital  Network-Basic  Access  Interface  for  Use  on  Metallic  Loops  for 
Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification)*  applies. 

7.2.2  Physical  Layer,  Basic  Access  at  S  and  T 

ANS  Tl  .605-1988,  "Integrated  Services  Digital  Network-Basic  Access  Interface  for  S  and  T  Reference  Points- 
Layer  1  Specification"  applies. 


7.2.3       Physical  Layer,  Primary  Rate  at  S,  T,  and  U 

ANS  Tl  .408-1 990,  "ISDN  Primary  Rate  -  Customer  Installation  Metallic  Interfaces  -  Layer  1  Specification" 
applies. 


14 


Part  2  -  Subnetworks 


September  1992  (Stable) 


7.2.4       Data  Link  Layer,  D-Channel 

CCITT  Recommendation  Q.921  (i.441),  ISDN  User-Network  Interface.  Data  Link  Layer  Specification"  applies. 


7.2.5  Signaling 

CCITT  Recommendation  Q.931  (1.451),  "ISDN  User-Network  Interface  Layer  3  Specification  for  Basic  Call 
Control"  applies. 

The  following  agreements  have  been  reached  concerning  the  use  of  Q.931: 

a)  On  a  Basic  Rate  Interface  supporting  the  ISDN  virtual  circuit  service,  all  of  Q.931  section  6 
except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched  access  case)  shall  apply.  The 
following  sections  also  apply:  2.2,  packet  mode  access  connection  states;  3.2,  messages  for  packet 
mode  access  connection  control;  4-4.5,  section  specifying  general  information  element  handling  and 
encoding;  4.7,  information  elements  for  packet  communications; 

b)  On  a  Primary  Rate  Interface  supporting  the  ISDN  virtual  circuit  service  all  of  Q.931  section  6  shall 
apply  except  for  6.1.1  and  6.2.1  (the  sections  specifying  the  circuit  switched  access  case),  6.1.2.2, 
6.2.2.2  and  6.4.2  (the  sections  specifying  D-Channel  ISDN  Virtual  Circuit  service  case).  The  following 
sections  also  apply:  2.2,  packet  mode  access  connection  states;  3.2,  messages  for  packet  mode 
access  connection  control;  4-4.5,  sections  specifying  general  information  element  handling  and 
encoding;  4.7,  information  elements  for  packet  communications; 

c)  On  a  Basic  or  Primary  Rate  Interface  supporting  the  unrestricted  64-Kbps  circuit-mode  service, 
Q.931  sections  6.1.1, 6.2.1, 6.4.1  and  6.4.3  shall  apply.  The  following  sections  also  apply:  2.1,  circuit 
mode  connection  states;  3.1,  messages  for  circuit  mode  connection  control;  4-4.5,  sections 
specifying  general  information  element  handling  and  encoding. 


7.2.6       Data  Link  i-ayer  B-Cliannei 

The  agreements  on  ISO  7776  specified  in  6.2  shall  apply  here. 

If  the  ISDN  provkies  a  circuit-mode  service  between  two  ISDN  packet-mode  devices,  then  the  layer  2 
address  shall  be  assigned  as  follows: 

a)  For  permanent  ("non-switched")  circuit-mode  service,  one  terminal  uses  address  A  and  the  other 
terminal  uses  address  B,  as  arranged  by  prior  agreement; 

b)  For  demand  ("switched")  circuit-mode  service,  the  terminal  originating  the  circuit-mode  call  uses 
address  A  and  the  other  terminal  uses  address  B. 
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7uS.7       Packet  Layer 

The  agreements  on  ISO  8208  specified  in  6.3  shali  apply  here.  When  ISO  8208  is  used  on  the  D-Channel. 
the  maximum  DATA  pacl(et  size  (i.e.,  actually  the  maximum  size  of  the  User  Data  Field  in  a  DATA  packet) 
shall  be  limited  to  256  octets. 


8    Frame  Relay  Subnetworks 


8.1  Introduction 

The  following  implementation  agreements  pertain  to  Frame  Relay  subnetworks.  These  agreements  are  to 
gukle  Implementors  on  optional  aspects  of  the  Frame  Relay  protocol  standards.  The  following  terminology 
is  used  in  this  clause: 

must,  shall  or  mandatory  -  the  item  is  an  absolute  requirement  of  this  implementatton 
agreement. 

should  -  the  item  is  hIgNy  desirable, 

may  or  optional  -  tlie  item  is  not  compulsory,  and  may  be  followed  or  Ignored  according 
to  the  needs  of  the  implementor. 


8.2     Relevant  Standards 


Nonmative  references  relevant  to  Frame  Relay  are  ANS  T1 .606,  and  its  addendum,  ANS  T1 .607,  ANS  T1 .61 7, 
ANS  T1 .618,  CCITT  Q.922,  and  CCITT  0.933. 

Addittonal  infonnation  relevant  to  Frame  Relay  is  found  in  CCITT  1.122,  and  CCITT  1.233.1. 


8.3     Implementation  Agreements 


8.3.1       Physical  Layer  Interface 

The  recommended  physical  layer  interfaces  supported  by  the  Frame  Relay  network  equipment  are  based 
on  American  National  Standards  and  CCITT  (Intematinai  Telegraph  and  Telephone  Consultative  Committee) 
Recommendations.  This  clause  provides  a  description  of  the  recommended  physical  layer  interfeces  that 
may  be  supported  by  a  Frame  Relay  equipment.  Interfaces  other  than  those  listed  below  may  be  used 
where  appropriate  (e.g.,  ISDN,  etc.).  If  the  recommended  interfaces  are  used,  they  should  be  used  as 
follows: 
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8.3.1 .1  ANS  T1 .403-1 989 

The  ANS  T1 .403-1989,  "Carrier  to  Customer  Installation  DS1  Metallic  Interface"  document  is  applicable  with 
the  following  exceptions: 

a)  Section  2.2  -  Other  Publications:  The  reference  to  CCITT,  Red  Book  Q921  Recommendation  is 
replaced  by  "CCITT,  Blue  Bool<,  Volume  VI  -  Fascicle  VI.  10.  Recommendation  Q.921.  Digital 
Subscriber  Signalling  System  No.  1  (DSS  1),  Data  Unl<  Layer." 

b)  Section  5.3.1  -  Transmission  Rate:  The  rate  variation  up  to  +/-200  bit/s  is  not  applicable. 

c)  Section  6.1  -  Framing  Format  General:  The  Superframe  (SF)  format  is  not  applicable. 

d)  Section  6.3  -  Superframe  Format:  This  section  is  not  applicat>le. 

e)  Section  7  -  Clear  Channel  Capability:  The  text  in  this  section  is  replaced  by  the  following:  To 
provide  DSI  Clear  Channel  Capability  (CCC),  a  DSl  signal  with  unconstrained  information  bits  is 
altered  to  meet  the  pulse  density  requirement  of  5.6.  The  method  is  used  to  provide  DS1  CCC  is 
B8ZS.  This  method  shall  be  used  in  both  directions  of  transmission. 

f)  Section  8  -  Maintenance:  The  mention  of  SF  format  and  the  associated  note  4  is  not  applicable. 

g)  Section  8.1  -  Yellow  Alarm:  Item  1  of  the  list  (Superframe  format)  and  associated  note  5  are  not 
applicable.  In  the  same  section;  item  3  of  the  list,  is  applicable  to  ESF  only. 

h)  Section  8.3.1.1  -  Line  Loopback  Using  the  SF  Format:  This  section  including  note  6  is  not 
applicable. 

I)  Section  8.4.3.3  -  Format  of  Message-Oriented  Performance  Report:  The  sentence  before  last: 
"Throughput  of  the  data  link  may  be  reduced  to  less  than  4  Kbit/s  in  some  cases"  is  not  applicable. 

j)  Section  8.4.5  -  Special  Carrier  Applications:  Item  3  of  the  list  and  note  12  are  not  applicable. 

k)  Table  2  -  Superframe  Format:  This  table  is  not  applicable. 

I)  Table  3  -  Extended  Superframe  Format:  The  portion  of  the  table  "Signaling  Bit  Use  Options"  and 
notes  related  to  Option  T.  Option  2,  Option  4,  and  Option  16  are  not  applicable. 

8.3.1.2  CCITT  Recommendation  V.35 

The  interface  specifications  are: 

a)  Electrical  characteristics  according  to  CCITT  Recommendation  V.35  Annex  1  and  V.28; 

b)  Connector  and  pin  assignment  according  to  ISO  2983; 

c)  Interchange  circuit  defintions  according  to  CCITT  Recommendation  V.24. 
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8.3.1.3  CCfTT  Recommendation  G.703  (2048  kbit/s) 
Applicable  sections  of  this  specification  are: 

a)  Introduction.  Except  those  references  which  are  to  1544  kbit/s; 

b)  Section  6.  Interface  at  2048  kbit/s; 

c)  Annex  A.  Definition  of  codes; 

d)  Annex  B.  Specifteation  of  the  overvoltageprotectbn  requirement,  in  additton,  when  the  75  ohm 
interface  is  implemented,  the  transmit  BNC  connector  shall  be  labeled  TFC  OUT  and  the  receive 
BNC  connector  shall  be  labeled  TFC  IN. 

8.3.1.4  CCITT  Recommendation  G.704  (2048  kbit/s) 

Applteable  sections  of  this  specification  are: 

a)  General; 

b)  Section  2.3.  Basic  frame  structure  at  2048  kbit/s; 

c)  Section  5.  Characteristics  of  frame  structures  carrying  channels  at  various  bit  rates  in  2048 
kbit/s  interfaces; 

d)  Annex  A.3.  CRC-4  procedure  for  interface  at  2048  kbit/s. 

NOTE  -  Section  1,  'General,'  specifies  the  electrical  interface  characteristics  to  be  CCITT  Recommendation 
G.703. 

8.3.1.5  CCITT  Recommendation  X.21  (non-switclied  operation) 

This  unstructured  interface  uses  the  leased  line  (i.e.,  non-switched  point  to  point)  subset  of  the  X.21 
Recommendation.  The  interface  specifteations  are: 

a)  Electrical  characteristics  according  to  CCITT  Recommendation  X.27  (V.1 1); 

b)  Connector  and  pin  assignment  according  to  ISO  4903; 

c)  interchange  circuit  definitions  according  to  CCITT  Recommendation  X.24. 


18 


Part  2  -  Subnetworks 


September  1992  (Stable) 


8.3.2      Data  Transfer 

Implementations  shall  be  baseti  on  ANS  T1 .618.  Implementation  agreements  on  the  optional  parts  of  ANS 
T1.618  are  proposed  as  follows: 


8.3.2.1        Section  2.2  Flag  sequence 

Interframe  time  fill  shall  be  accomplished  by  transmitting  one  or  more  contiguous  HDLC  flags  with  the  bit 
pattern  '01 1 11 1 10'  when  the  data  link  layer  has  no  frames  to  send. 


8.3.2.2        Section  2.5  Frame  relay  information  field 

A  maximum  frame  relay  information  field  size  of  1600  octets  shall  be  supported  by  the  network  and  the  user, 
in  addition,  maximum  information  field  sizes  less  than  or  greater  than  1600  octets  may  be  agreed  to  between 
networks  and  user  at  subscription  time. 
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8.3.2.3  Section  3.3  Address  field  variables 

See  the  following: 

a)  Section  3.3.1  Length  of  address  field; 

1)  An  address  field  of  2  octets  shall  be  supported.  (All  frames  must  have  the  EA  bit  set 
to  0  in  the  first  octet  of  the  address  field  and  the  EA  bit  set  to  1  in  the  second  octet  of  the 
address  field); 

2)  The  3- and  4-octet  address  formats  are  outside  the  scope  of  this  agreement; 

b)  Section  3.3.6  Data  linl<  connection  identifier; 

1 )  The  2  octet  address  forniat  shall  be  supported  with  DLCI  values  as  defined  in  table  1  (a) ; 

c)  Section  3.3.6.2  DLCI  on  the  D-channel; 

1)  This  section  is  not  applicable  for  Permanent  Virtual  Connections  (PVCs); 

d)  Section  3.3.7  DLCI  or  DL-CORE  control  indicator  (D/C); 

1)  This  section  is  not  applicable. 
Other  address  structure  variables  and  their  usage  are  as  specified  in  ANS  T1.618. 

8.3.2.4  Section  5  Congestion  control 

Congestion  control  strategy  for  Frame  Relay  is  defined  in  ANS  T1.606  Addendum  1.  The  following 
implementation  agreements  apply  to  network  equipment  and  user  equipment  respectively: 

a)  Section  5.1  Networi<  response  to  congestion 

1)  Mandatory  procedures  of  ANS  T1.606  Addendum  1  shall  be  implemented.  When 
implemented,  rate  enforcement  using  the  DE  indicator,  and /or  setting  of  the  FECN  and 
BECN  indicators,  should  be  implemented  according  to  T1.606  Addendum  1. 

b)  Section  5.2  User  response  to  congestion 

1)  User  equipment  reaction  is  dependent  on  the  protocols  operating  over  the  Data  Link 
Core  sublayer.  It  is  recommended  that  the  procedures  of  ANS  T1 .618  Annex  A  should  be 
implemented  where  appropriate. 

I 
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8.3.2.5        Section  6  Consolidated  link  layer  management  (CLLM)  message 

Use  of  the  CU-M  message  is  not  required. 


8.3.3 


Control  (Signaling)  procedures 


8.3.3.1 


Permanent  Virtual  Connections  (PVC)  procedures 


a) 


a)  Managing  PVCs  on  a  bearer  ciiannel  that  only  supports  PVCs:  User  devices  (and  the  networi() 
shail  implement  the  mandated  procedures  of  Annex  D  of  ANS  T1.617.  In  addition,  Annex  B  and 
optional  procedures  of  Annex  D  of  ANS  T1 .61 7  may  also  be  implemented.  By  bilateral  agreement: 

1)  Optional  procedures  of  Annex  D  of  ANS  T1.617  may  be  used; 

2)  Annex  B  may  be  used  instead  of  Annex  D. 

Implementation  Note  -  The  numt)er  of  PVCs  that  can  be  supported  by  Annex  D  is  limited  by  the  maximum 
frame  size  that  can  be  supported  by  the  user  equipment  and  the  network  on  the  bearer  channel  (e.g.,  when 
the  maximum  frame  relay  information  field  size  is  1 600  octets  then  a  maximum  of  31 7  PVC  status  information 
elements  may  be  encoded  in  a  STATUS  message). 


b)  Managing  PVCs  on  a  boarer  channel  where  switched  virtual  connections  (SVCs)  and  PVCs  co- 
exist:   User  devices  (and  the  network)  shall  implement  Annex  B  of  ANS  T1.617. 


b) 


8.3.3.2 


Switched  Virtual  Connections  (SVCs)  procedures 


The  implementation  agreements  for  SVCs  will  be  provkied  later. 
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Annex  A  (informative)  

Cross  Reference  Between  CCITT  and  ANSI  Text  Relating  to  ISDN 
Agreements 

This  annex  provides  a  cross-reference  listing  between  those  sections  of  the  CCITT  ISDN  Recommendations 
given  in  clause  7  of  this  document  and  the  sections  of  the  corresponding  ANSI  ISDN  Standards.  This 
appendix  does  not  supersede  clause  7  but  merely  provides  a  pointer  to  those  who  wish  to  implement  the 
ISDN  procedures  based  on  ANSI  Standards. 

A.1      Data  Link  Layer,  D-Channel 


CCITT  Recommendation  Q.921,  which  Is  referenced  In  7.2.4  of  this  document,  is  identical  to  ANSI  Standard 
T1.602. 


A.2  Signaling 

The  following  table  provides  the  cross-references  between  those  sections  of  CCITT  Recommendation  Q.931 
referenced  in  7.2.5  of  this  document  and  the  corresponding  ANSI  ISDN  Standards. 


Table  1  -  ANSI-CCITT  crossrreferences 


CCITT  RECOMMENDATION  Q.931 

ANS  T1.608 

Section 

2.1 

Section 

4.1  (refers  to  sec. 

2.1.1 

of  ANS  T1.607) 

Section 

2.2 

Section 

4.2 

Section 

3.1 

Section 

5.1  (refers  to  sec. 

3  of  ANS  T1.607) 

Section 

3.2 

Section 

5.2 

Section 

4.1 

Section 

6.1 

Section 

4.2 

Section 

6.2 

Section 

4.3 

Section 

6.3 

Section 

4.4 

Section 

6.4 

Section 

4.5 

Section 

6.5 

Section 

4.7 

Section 

6.5 

Section 

6 

Section 

7 

Section 

6.1.1 

Section 

7.1.1 

Section 

6.1.2.2 

Section 

7.1.2.2 

Section 

6.2.1 

Section 

7.2.1 

Section 

6.2.2.2 

Section 

7.2.2.3 

Section 

6.4.1 

Section 

7.4.1 

Section 

6.4.2 

Section 

7.4.2 

Section 

6.4.3 

Section 

7.4.3 
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Annex  B  (informative) 
Bibliography 


B.1  ANSI 

ANS  T1 .607-1 989.  Telecommunications  -  Digital  Subscriber  Signaling  System  #1  -  Layer  3  Signaling 
Specification  for  Circuit  Switclied  Bearer  Service. 

ANS  T1 .608-1989,  Telecommunications  -  Digital  Subscriber  Signaling  System  #1  -  Layer  3  Signaling 
Specification  for  Pacl<et  Switched  Bearer  Service. 


B.2  CCITT 

CCITT  Recommendation  1.122,  Framework  for  Providing  Additional  Pacl^et  Mode  Bearer  Services,  1988. 

CCITT  Recommendation  1.233.1,  ISDN  Frame  Mode  Bearer  Services  (FRBS)-ISDN  Frame  Relaying  Bearer 
Service,  (proposed  1991). 

CCITT  Recommendation  1.430  (Blue  Book),  Basic  User-Network  Interface  -  Layer  1  Specification. 


B.3  ISO 

ISO  9314-1 :18©9,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  1:  Token 
ring  physical  layer  protocol  (PHY). 


ISO  9314-3:  1990,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  2:  Token 
ring  media  access  control  (MAC). 


ISO  9314-3:  1990,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  3: 
Physical  layer  medium  dependent  (PMD). 


B.4  OTHER 


FIPS  107.  Local  Area  Networks:  Baseband  Canier  Sense  Multiple  Access  with  Collision  Detection  Access 
Method  and  Physical  Layer  Profiles  and  Link  Layer  Protocol,  NTIS.  U.S.  Department  of  Commerce,  5285  Port 
Royal  Road,  Springfield,  VA  22161. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW).  See  Procedures  Manual  for 
Workshop  charter. 

Text  In  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject. 

Annex  A  is  for  information  only. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  3  -  Network  Layer 


0  Introduction 

This  part  presents  agreements  for  providing  tlie  OS!  network  service.  Also  contained  here  are  agreements 
on  network  layer  addressing  and  routing. 


1  Scope 

These  agreements  cover  both  connectionless-mode  and  connection-mode  network  services. 


2    Normative  References 


2.1  CCITT 

[1]      Recommendation  X.213  (Blue  Book,  1988).  Network  Service  Definition  for  Open  Systems 
Interconnection  for  CCITT  Applications. 


2.2  ISO 

[2]       ISO  8348.  Information  processing  systems  -  Data  communications  -  Network  service  definition. 

[3]  ISO  8348  Addendum  1 ,  Information  processing  systems  -  Data  communications  -  Network  sen/ice 
definition  -  Addendum  1:  Connectionless-mode  transmission. 

[4]  ISO  8348  Addendum  2.  Information  processing  systems  -  Data  communications  -  Network  service 
definition  -  Addendum  2:  Network  layer  addressing. 

[5]  ISO  8473,  Information  processing  systems  -  Data  communications  -  Protocol  for  providing  tiie 
connectionless-mode  network  sen/Ice. 

[6]  ISO  8648,  Information  processing  systems  -  Open  systems  interconnection  -  Internal  organization 
of  the  Network  Layer. 

[7]  ISO  8878,  Information  processing  systems  -  Data  communications  -  Use  of  X.25  to  provide  tiie  OSI 
connection-mode  network  sen/ice. 

[8]  ISO  8881 ,  Infonnation  processing  systems  -  Oa(a  communications  -  Use  of  tiie  X.25  packet  level 
protocol  In  local  area  networks. 

[9]  ISO  9542,  Infonnation  processing  systems  -  Telecommunications  and  information  exchange 
tyetween  sysfe/ns  -  End  system  to  Intermediate  system  routing  exchange  protocol  for  use  in 
conjunction  with  the  Protocol  for  providing  the  connectionless-mode  service  (ISO  8473). 
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[10]  ISO/IEC  9574.  Information  technology  -  Telecommunications  and  Information  excfiange  between 
systems  -  Provision  of  the  OSl  connection-mode  network  sen/Ice  by  packet  mode  terminal 
equipment  connected  to  an  Integrated  services  digital  network  (ISDN). 

[1 IJ  ISO/IEC  TR  9577,  Information  technology- Telecommunications  and  information  exchange  between 
systems  -  Protocol  identification  in  the  network  layer. 

[12]  ISO/IEC  TR  10029,  Information  technology  -  Telecommunications  and  information  exchange 
between  systems  -  Operation  of  an  X.25  Interworking  unit. 

[13]  ISO/IEC  1 0030,  Information  processing  systems  -  Telecommunications  and  information  exchange 
between  systems  -  End  system  routeing  information  exchange  protocol  for  use  in  conjunction  with 
ISO  8878. 

[14]  ISO/IEC  1 0589,  Information  technology  -  Telecommunications  and  Information  exchange  between 
systems  -  Intermediate  system  to  intermediate  system  Intro-domain  routeing  exchange  protocol  for 
use  In  conjunction  with  the  protocol  for  providing  tiie  connectionless-mode  network  service  (ISO 
8473). 

'  ISOySBO  01$  11577,  Mom^^em  TotMohgy  -  Tei^tc^mmMim  md  tt^cme^m  Bdih&fm 
3  Status 

This  version  of  the  agreements  was  completed  in  December  1990. 


4  Errata 

This  clause  may  contain  "Defect  Report"  and  resolutions  material,  and  the  versions  of  impiementor 
agreements  to  which  this  material  applies. 

The  following  defects  are  t>eing  progressed  in  ISO: 

a)  ISO  9542,  defect  1,  Parts  1-13; 

b)  ISO  9542,  defect  2; 

i     c)  ISO  8473,  defects  1  through  11,  and  technical  corrigendum  1; 
d)  ISO/IEC  10589,  defect  1. 


5    Connectionless-Mode  Network  Service  (CLNS) 
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5.1 


ISO  8473 


NOTE  -  Defect  reports  upon  the  base  standard  have  been  issued.  See  clause  4  of  this  part  for  further 
information. 


5.1.1       Subsets  of  the  Protocol 

Agreements  on  subsets  of  the  protocol  are  as  follows: 

a)  Implementatioris  wil  qs&  transmit  PDUs  encoded  using  the  Inactive  sut>set.  Received  PDUs 
encoded  using  the  inactive  subset  wfll  be  discarded: 

b)  The  non-segmenting  subset  wHI  qs^  be  used,  implementations  will  ns^  generate  data  PDUs 
without  a  segmentation  part.  IHowever.  Implementations  will  receive  and  correctly  process  PDUs 
which  do  not  contain  the  segmentation  part. 


5.1.2       Mandatory  Functions  of  ISO  8473 

Agreements  on  Mandatory  Functions  of  ISO  8473  are  as  follows: 

a)  The  lifetime  parameter  shall  be  used  as  specified  in  clause  6.4  of  ISO  8473.  The  parameter  shall 
have  an  Initial  value  of  at  least  three  times  the  network  span  or  three  times  the  maximum  transit 
delay  (in  units  of  500  ms),  whichever  is  greater; 

b)  The  reassembly  timer  for  an  initial  PDU  at  the  reassembly  point  shall  be  no  greater  than  the 
largest  value  of  ail  lifetime  parameters  contained  in  ail  derived  PDUs; 

c)  The  use/non-use  of  checksums  shall  be  capable  of  being  configured.  The  deteult  setting  shaH 
be  noTHise; 

d)  if  the  implementation  supports  the  generatkm  of  an  ER  PDU,  the  system  shall  Insert  in  the 
destination  address  fieki  of  the  ER  PDU  the  contents  of  the  source  address  fiekJ  of  the  PDU  that 
generated  the  error; 

e)  For  the  purposes  of  relaying  and  routing,  a  protocol  entity  need  not  verify  the  correctness  of  ISO 
8348/Add.  2  semantics  canled  in  NPAI  of  received  PDUs. 


5.1.3      Optional  Functions  of  ISO  8473 

Agreements  on  Optk)nal  Functkms  of  ISO  8473  are  as  follows: 

a)  The  Security  parameter  is  not  defined  by  these  Agreements.  implementatk>ns  shall  not  transmit 
the  parameter  except  wfiere  defined  by  bUaterai  agreements; 
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b)  Partial  and  complete  source  routing  will  ngt  be  supported;^ 

c)  Partial  record  of  route  will  be  supported  by  Intermediate  systems; 

d)  ISO  8473  will  be  followed  with  respect  to  QOS; 

e)  For  systems  implementing  the  congestion  notification  function,  the  following  applies: 

1)  A  Globally  Unique  QOS  Maintenance  parameter  shall  be  included  in  all  PDU  originated 
by  End  Systems.  As  specified  in  ISO  8473,  the  initial  value  of  the  Congestion  Experienced 
flag  (CE  flag)  within  the  Globally  Unique  QOS  Maintenance  Parameter  shall  be  set  by  the 
originating  End  System  to  zero.  All  other  flags  within  the  Globally  Unique  QOS  Maintenance 
Parameter  shall  be  set  based  on  the  specific  local  needs  of  the  originating  End  System; 

2)  Intermediate  systems  not  implementing  queue  length  averaging  shall  leave  the  CE  flag 
in  the  same  state  as  it  was  received.  In  particular,  no  intermediate  system  (IS)  shall  ever 
clear  (set  to  zero)  the  CE  flag.  All  intermediate  systems  shall  monitor  all  incoming  and 
outgoing  queues  and  compute  average  queue  lengths  as  shown  by  example  in  figure  1 . 
The  averaging  is  done  from  the  beginning  of  the  previous  cycle  to  the  current  time.  A  cycle 
begins  at  the  instant  of  the  first  NSDU  arrival  after  an  idle  period; 

3)  An  IS  should  set  the  CE  flag  in  all  NSDUs  fon/varded  on  a  queue  which  has  an  average 
queue  length  greater  than  one; 

4)  The  queue  length  averaging  algorithm  computes  the  average  queue  length  over  two 
cycles,  where  the  two  cycles  are: 

a)  the  "previous  cycle",  which  is  the  interval  from  when  the  IS  becomes  busy,  until 
it  becomes  idle  and  the  idle  ends  (indicated  by  the  instant  the  first  packet  arrives 
to  the  idle  IS); 

b)  the  "current  cycle",  which  is  the  interval  from  the  end  of  the  idle  interval  to  the 
current  time  instant  when  the  average  queue  length  is  computed; 

5)  An  embodiment  of  the  averaging  algorithm  is  shown  in  figure  1 ; 

f)  Refer  to  the  Working  Implementation  Agreements  document  for  additional  optional  functions. 


A  defect  exists  with  the  Partial  Source  Routing  option  which  can  cause  PDUs  to  loop  in  the 
network  until  their  lifetime  expires. 
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The  algorithm  aakes  use  of  the  following  variables: 
t  «  Current  time 

t^  s  time  of  i^"  arrival  or  departure  event 

«  number  of  packets  in  the  system  after  the  event 
Tq  «  time  at  the  beginning  of  the  previous  cycle 
T]^  ■  time  at  the  beginning  of  the  current  cycle 

The  algorithm  consists  of  three  components: 

1.  Queue  Length  Update:  Beginning  with  qQ  =  0, 

If  the  i*|*  event  is  an  arrival  event,  q^  =  q^.^+l 
If  the  i^"  event  is  a  departure  event,  q^  =  q^.^^-l 

2.  Queue  Area  (integral)  update: 

Area  of  the  previous  cycle  =  Z    q4  i(ti-t{  i) 

tiCCToiTj) 

Area  of  the  current  cycle  =  S    q^  i(ti-t{  i) 

tiC{Ti,tt 

3.  Average  Queue  Length  Update: 

Average  Queue  length  over  the  two  cycles 

Area  of  the  two  cycles     Area  of  the  two  cycles 

K   S  — — — — 

Time  of  the  two  cycles  t-Tn 


Figure  1  -  Queue  length  averaging  algorithm 

5.2      Provision  of  CLNS  over  Local  Area  Networlcs  (LANS) 

When  providing  CLIJS  over  a  LAN  subnetwortc.  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  In  ISO  8348/Add.  1 ; 

b)  The  protocol  used  to  provide  CUMS  shall  be  ISO  8473  v«^lth  agreements  as  specified  in  5.1; 

c)  The  necessary  subnetworl(  dependent  convergence  function  shall  Ise  as  defined  in  ISO  8473 
clause  8.4.2.  "SNDCF  used  with  ISO  8802/2  sub-networi<s." 
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5.3  Provision  of  CLNS  over  X.25  Subnetworks 

When  providing  CUMS  over  X.25  subnetworl<s,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1 ; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1 ; 

c)  The  necessary  subnetwork  dependent  convergence  function  shall  be  as  defined  in  ISO  8473  - 
clause  8.4.3,  'SNDCF  used  with  ISO  8208  subnetworl<s  for  operation  over  X.25  subnetworks,"  and 
the  default  throughput  class  shall  be  used  if  this  facility  is  available; 

d)  The  X.25  PLP  shall  be  as  specified  in  part  2  clause  6.3. 

5.4  Provision  of  CLNS  over  ISDN 

When  providing  CLNS  over  an  ISDN,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1 ; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  Subnetwork  Dependent  Convergence  function  shall  be  as  defined  in: 

1)  ISO  8473  for  operation  of  CUMP  over  X.25  with  agreements  as  specified  in  5.3; 
.   2)  ISO  9574  for  control  of  the  B  and  D  channels; 

3)  The  X.25  PLP  shall  be  as  specified  in  part  2,  clause  6.3; 

4)  The  agreements  for  the  ISDN-related  protocols  are  specified  in  part  2,  clause  7. 

NOTE  -  The  stated  scope  of  ISO  9574  does  not  explicitly  cover  the  operation  of  CLNP  over  an  ISDN. 
However,  the  procedure  identified  for  operating  X.25  in  conjunction  with  1.451  is  still  applicable.  The  procedures 
in  ISO  9574  that  correspond  to  8878  are  not  utilized  v«/hen  providing  CLNS. 

5.5  Provision  of  CLNS  over  Point-to-Point  Links 

Refer  to  the  Working  Implementation  Agreements  document. 

6    Connection-Mode  Network  Service  (CONS) 

The  following  agreements  concern  provision  of  the  connection-mode  Network  Service. 
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6.1      Mandatory  Method  of  Providing  CONS 


6.1.1  General 

Independent  of  the  subnetwork  type  (of  part  2),  when  providing  the  CONS  using  X.25-1984,  the  following 
shall  apply  as  described  below: 

a)  The  definition  of  the  CONS  is  as  specified  in  ISO  8348.  Network  Service  Definition: 

b)  The  mapping  of  the  elements  of  the  CONS  to  the  elements  of  the  X.25  Packet  Layer  Protocol 
(PLP)  is  as  specified  in  6.3.1; 

c)  The  general  procedures  and  fomnats  of  the  X.25  PLP  are  as  specified  in  ISO  8208,  X.25 
Packet  Layer  Protocol  for  Data  Terminal  Equipment. 


6.1.2        X.25  WAN 

No  provisions  additional  to  those  in  6.1.1  apply  in  an  X.25  WAN. 


6.1.3  UVNs 

When  provkiing  the  CONS  in  a  Local  Area  Network,  the  following  aspects  of  ISO  8881,  in  addition  to  the 
documents  listed  in  6.1.1,  shall  apply: 

a)  Qauses  1-6  and  9-11  for  LLC  Type  1  operation,  including  the  additional  nonstandard  deteult 
packet  size  listed  in  Clause  6.3,  Note  2. 

NOTE  -  Operation  of  ISO  8208  In  conjunction  with  LLC  Type  2  requires  agreement  on  U.C  Type  2 
procedures. 


6.1.4  ISDN 

When  provkJing  the  CONS  in  an  ISDN,  the  conskJerations  for  control  of  a  B  and  D  channel  in  ISO  9574, 
In  addition  to  those  provided  in  6.1.1,  shall  apply. 
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6.2  Additional  Option:  Provision  of  CONS  over  X.25  1980 
Subnetworks 

When  providing  CONS  over  an  X.25  1980  subnetwork,  the  following  shall  apply: 

a)  Tho  Hftfinitinn  nf  thft  roNfi  is  as  spflfiiflflri  in  ISO  8348.  Network  Service  Definition: 

b)  The  subnetwork  dependent  convergence  protocol  required  to  provkle  CONS  shall  be  as 
specified  in  ISO  8878  Annex  A,  and  referred  to  as  the  Alternative  Procedures  for  Network 
Connection  Establishment  and  Release,  with  agreements  as  defined  in  6.3.2. 

6.3  Agreements  on  Protocols 

6.3.1  ISO  8878 

ISO  8878  Clauses  1-11  shall  apply  with  the  following  exception: 

a)  Where  the  ISO  8208  diagnostic  codes  are  not  provided,  all  Cause/Diagnostic  code 
combinations  can  be  mapped  to  the  Originator/Reason  code  of  'Undefined." 

6.3.2  Subnetwork  Dependent  Convergence  Protocol  (ISO  8878/Annex  A) 

The  Receipt  Confirmation  service  will  not  be  provided,  so  the  corresponding  protocol  elements  need  not 
be  implemented. 

The  Expedited  Data  service  will  not  be  provkJed,  so  the  corresponding  protocol  elements  need  not  be 
implemented. 


6.4  Interworking 

InteoA^orklng  between  subnetworks  whose  End  Systems  use  ISO  8208  to  provide  the  CONS  as  specified 
in  6.1  shall  be  performed  as  specified  in  ISO  TR  10029.  That  is,  an  Intemnediate  System  connecting  two 
such  subnetworks  shall  operate  ISO  8208  on  both  subnetworks  and  shall  relay  infonnation  from  one 
subnetwork  to  the  other  as  described  in  ISO  TR  10029. 


7  Addressing 

NSAP  address  fornr>ats  supported  will  confonn  to  Addendum  2  of  ISO  8348  as  follows: 

a)  NSAP  address  formats  will  have  a  hierarchical  structure.  This  will  reduce  the  size  of  routing 
tables; 
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b)  If  used  in  the  Domain  Specific  Part  (DSP),  an  NSAP  selector  shall  be  the  least  significant 
component  in  the  hierarchy,  and  shall  be  encoded  as  the  last  octet  of  the  DSP.  The  NSAP 
selector  shall  not  be  used  to  perform  routing;  it  is  simply  Intended  to  identify  the  network  service 
user  at  the  destination  end  system.  For  those  implementations  using  an  NSAP  selector,  there 
shall  be  one  and  only  one  selector  for  each  NSAP  within  the  end  system.  Ail  NSAP  addresses 
identifying  a  given  NSAP  will  use  the  same  NSAP  selector  value. 

c)  In  routing  environments  In  which  systems  support  NSAP  addresses  containing  selectors  as 
specified  In  b),  the  corresponding  Network  Entity  Titles  shall  have  the  same  format  with  the 
NSAP  selector  set  to  zero. 

d)  End  Systems  and  Intermediate  Systems  operating  in  routing  domains  that  employ  the  ISO 
10589  Intradomain  Routing  Protocol  shall  meet  the  NSAP/NET  addressing  requirements 
specified  in  ISO  10589  (clause  7.1)  and  clause  8.3  of  these  agreements. 


NOTE  -  This  may  be  incompatible  with  systems  implemented  according  to  previous  versions  of  these 
agreements. 


8  Routing 

The  t>asic  principles  of  Network  Layer  routing  are  defined  in  the  OSI  Routing  Framework  ISO/IEC  TR 
9575.  These  principles  state  that: 

a)  The  global  OSI  environment  will  consist  of  a  number  of  Administrative  Domains,  An 
Aidministrative  Domain  consists  of  a  coilection  of  End  Systems  (ESs)  and  intermediate  Systems 
(ISs).  and  subnetworks  operated  by  a  single  organization  or  Administrative  Authority.  The 
Administrative  Authority  Is  responsible  for:  the  organization  of  ESs  and  ISs  into  Routing 
Domains;  the  assignments  of  NSAP  and  SNPA  addresses;  the  policies  that  govern  resource 
usage;  the  policies  that  govern  the  information  that  is  collected  and  disseminated  both  internally 
and  externally  to  the  Administrative  Domain;  and  the  establishment  of  subdomains  and  the 
corresponding  delegation  of  responsibilities; 

b)  A  Routing  Donr^in  Is  a  set  of  ESs  and  ISs  which  operate  according  to  the  same  routing 
procedures  and  which  is  wholly  contained  within  a  single  Administrative  Domain.  An 
Administrative  Authority  may  delegate  to  the  entity  responsible  for  a  Routing  Domain  the 
responsibilities  to  further  structure  and  assign  NSAP  and  SNPA  addresses.  The  hierarchical 
decomposition  of  Routing  Domains  into  subdomains  may  greatly  reduce  the  resources  required 
In  the  maintenance,  computation,  and  storage  of  routing  information; 

c)  The  OSI  routing  problem,  and  consequently  OSI  routing  protocols,  has  been  decomposed 
Into  three  distinct  classes: 

1)  End  System  (ES)  to  Intemnediate  System  (IS)  routing  within  a  single  subnetwork; 

2)  IS  to  IS  routing  within  a  single  routing  domain  (Intra-domain); 

3)  IS  to  IS  routing  between  routing  domains  (Inter-domain). 
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8.1      ISO  9542  End  System  to  Intermediate  System  Routing 

NOTE  '  Defect  reports  upon  the  base  starKiard  have  been  issued.  See  dause  4  of  this  part  for  further 
irrfonnation. 

For  use  in  conjunction  with  ISO  8473.  ISO  9542  shall  be  used  to  provide  the  routing  exchange  protocol. 

Additionally,  a  management  mechanism  capable  of  adding  and  deleting  entries  into  the  Routing 
Information  Base  (RIB)  is  recommended.  When  using  the  management  mechanism  to  add  an  entry, 
there  should  be  no  holding  timer,  and  the  entry  should  be  write  protected  from  alteration  by  the  ES-IS 
protocol.  This  mechanism  enables  routing  table  entries  to  be  made  which  are  static  In  nature. 

The  agreements  below  apply  to  the  use  of  ISO  9542: 

a)  Implementors  shall  support  any  valid  NSAP  format.  For  the  purposes  of  the  protocol,  NSAP 
addresses  are  treated  simply  as  octet  strings; 

b)  For  l^s,  implementors  shall  support  both  Configuration  infomnation  and  Route  Redirection 
Information:  no  subsets  are  permitted.  For  X25  subnetwori(s.  Route  Redirection  Information 
shall  be  supported; 

c)  Ail  timer  values  shall  be  configurable; 

d)  Use  or  non-use  of  checksums  shiali  be  configurable,  it  is  recommended  not  to  use  ISO  9542 
checksums  when  originating  PDUs; 

e)  The  QOS.  Security  arxJ  Priority  parameters  shoukJ  not  be  used  for  routing.  For  conformance, 
intermediate  systems  must  transmit  these  parameters  in  RD  PDUs  If  they  are  present  in  the  data 
PDU  whtoh  generated  the  redirect.  However,  end  systems  must  Ignore  them  in  received  RD 
PDUs: 

f)  If  the  configuration  notification  functk)n  described  in  6.7  of  the  protocol  specifteation  is 
implemented,  a  mechanism  shall  be  provkied  to  enable/disable  this  functk>n  on  broadcast 
networks.  If  supported  in  end  systems  listening  to  both  iSI-is  and  ESHs.  this  functkm  shall  only 
be  invoked  upon  receipt  of  an  ISH.  Alternate  mechanisms  for  ISs  and  ESs  are  described  in  8.1.1 
and  8.1.2. 

g)  For  LANs,  this  protocol  employs  the  same  LSAP  as  ISO  8473; 

h)  The  encoding  of  the  BSNPA  address  follows  the  syntax  mies  for  the  data  link  being  used.  On 
a  LAN.  for  example,  it  is  a  48-bit  MAC  address  encoded  as  specified  in  clause  12.2.1.4  of  ISO 
10039.  On  X.25  subnetworics,  It  is  a  DTE  address,  each  digit  being  binary  coded  In  a  semi-octet, 
and.  If  there  are  an  odd  number  of  digits,  an  additional  semi-octet  set  to  the  value  1111  shall  be 
added  at  the  end; 

i)  The  multicast  addresses  con'esponding  to  'All  Intermediate  Systems  on  the  Network" 
(ALLJSN)  and  'All  End  Systems  on  the  Networic"  (AU.  ESN)  shall  default  to  the  following  on 
IEEE802.3  and  IEEE802.4  subnetworics: 
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1)  ALL  ESN  =  09-00-2B-00-00-04,  ALLJSN  =  09-00-2B-00-00-05; 

2)  It  Is  understood  that  the  hexadecimal  octets  shown  are  transmitted  onto  the  medium 
from  left  most  octet  to  right  most  octet.  Within  each  hexadecimal  octet  the  least 
significant  bit  Is  transmitted  first; 

1^  wMn  <^?er8iting  ont  a  «p$clflo  tBE^       mbrmmnk    £$$  mnd      $h«M  u$B  0>foftj$ively 
^rtther  iPuncational  Addresses  or  Oroap  Addresses  for  iBne  operation  df  ISO  9542.  It  Is  strong 
rooommetyled  th^  Oroup  Adctr^n^  b0  M$dd  po$$il?)^o. 

for  iWSB  802.6  ifiiH^  In  Which  Otoup  Acldr«9$li0  $upport^  by  sii  ?iftd  i^s,  the  iiwltJc$$t 
6Ki(|r«S8ds  corresponding  ite^  'AS  inlainBdiEiite  Systems  tm  i\m  fieltwQ^  (fiiLJ^t^  and  "All  End 
iSyi^ms  OB  th0  fretwork*  (AtLjEi^)      be  as  fottows: 

For  IEEE  802.$  LAN^  in  vi^iloh  Fu»o!lan^  Addressing  tng$r  be  used,  the  i$0  9542  miitlqasr  $h^l 

1)  Mi,-E$N  «  QS'OO'OO^^JO^amAULJ^  «  03^^^<KMJ1^. 
SdKor^e  flote  «  Wh^n  trau^mittsil  oi^  the  m6(i\uf%  ism  above  9<Mt^$sm       be  (presented  e$ 

k)  The  Error  Report  flag  shall  be  set  to  zero  (0)  for  NPDUs  sent  as  a  result  of  invoking  the 
QUERY  Configuration  Function. 

I)  ISO  8473  PDUs  multicast  as  a  result  of  the  Query  Configuration  function  shall  use  the 
Network  Layer  Protocol  ID  (NLPID)  assigned  to  ISO  8473. 

m)  An  ISO  8473  PDU  received  as  a  result  of  another  ES  having  performed  the  Query 
Configuration  function  shall  be  processed  as  follows: 

1)  If  the  ISO  8473  PDU  is  addressed  to  one  of  the  NSAPs  present  in  the  ES,  the  End 
System  shall  process  the  PDU  according  to  the  applicable  clauses  of  ISO  8473  and 
invoke  the  Configuration  Response  Function  (clause  6.6  of  ISO  9542); 

2)  If  the  ISO  8473  PDU  is  not  addressed  to  one  of  the  NSAPs  present  in  the  ES,  the 
End  System  shall  discard  the  PDU  without  generating  an  ISO  8473  Error  Report; 

n)  For  purposes  of  address  matching  and  SNPA  extraction,  the  first  octet  of  the  option 
parameter  value  of  an  address  (clause  7.4.5)  or  SNPA  Mask  (clause  7.4.6)  shall  be  aligned  with 
the  first  octet  (AFI)  of  the  encoded  trial  NSAP  Address. 

The  following  items  represent  proposed  solutions  to  defects  in  ISO  9542.  These  solutions  are  being 
progressed  as  defect  reports  to  ISO  9542.  These  items  will  be  deleted  when  the  corresponding  defect 
report  is  approved: 
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a)  An  End  System  may  choose  to  Ignore  an  RD  PDU  received  for  a  destination  to  which  the  ES 
has  not  sent  traffic  for  some  period  of  time.  An  ES  must  record  redirection  information  only  for 
those  other  systems  with  which  it  is  in  active  communication; 

b)  A  holding  time  value  of  zero  is  permitted.  When  configuration  and/or  redirection  infomiation 
with  a  zero  holding  time  is  received,  prior  Infomiatlon  shall  be  replaced,  thus  causing  the  system 
to  set  its  holding  timer  to  zero  and  discard  the  corresponding  Information; 

c)  If  one  or  more  ISs  suggested  an  ESCT,  the  minimum  of  the  non-zero  suggested  values 
replaces  the  current  value  of  the  ES's  CT. 


8.1.1       Alternative  Configuration  Mechanism  -  IS  Actions 

An  alternative  mechanism  for  achieving  rapid  configuration  which  is  scaleable  to  large  broadcast 
networks  is  described  below.  This  mechanism  makes  use  of  the  Suggested  ES  Configuration  Timer. 
Implementation  of  this  mechanism  Is  optional. 

When  an  Intermediate  system  wants  to  quickly  acquire  the  End  system  configuration  (for  example,  when 
a  broadcast  circuit  is  enabled  on  the  IS  or  the  topology  changes  because  of  a  failure  of  a  bridge  or 
repeater),  it  initiates  a  'poll"  of  the  End  system  configuration  by  performing  the  following  actions: 

a)  Delay  a  random  interval  between  0  and  PollESHelloRate  seconds.  (This  is  to  avoid 
synchronization  with  other  ISs  which  have  detected  a  change.); 

b)  In  order  to  rapidly  time  out  any  End  systems  which  are  no  longer  present  on  the  broadcast 
circuit  (for  example,  after  a  LAN  partition),  reset  the  entryRemainingTime  in  the  Routing 
Information  Base  for  all  End  systems  on  this  circuit  to  the  value:  (ISHelloTimer  + 
PollESHelloRate)  *  HoldingMuKlpller  or  the  existing  value  whichever  is  lowest.  Where 
ISHelloTimer  is  the  Intermediate  system's  configuration  timer,  HoldingMultipller  is  a  predefined 
number  (for  example,  2)  which  multiplied  by  ISHelloTimer  gives  the  value  for  the  Holding  Time 
field  of  IS  Helios; 

c)  Then  transmit  HoldingMultipller  IS  Helios  with  a  Suggested  ES  Configuration  Timer  value  of 
PollESHelloRate  seconds  with  an  inten/al  of  ISHelloTimer  seconds  between  each  and  setting  the 
Holding  Time  field  to  ISHelloTimer  *  HoldingMultipller; 

d)  Then  start  sending  IS  Helios  with  a  Suggested  ES  Configuration  Timer  of  DefaultESHelloRate 
seconds  (where  DefaultESHelloRate  is  larger  than  PollESHelloRate). 


8.1.2       Alternate  Configuration  Mechanism  -  ES  Actions 

An  End  system  maintains  for  each  circuit  a  list  (CTLIst)  which  has  HoldingMultiplier  elements  each  of 
which  stores  a  received  value  of  the  Suggested  ES  Configuration  Timer.  The  function  SaveCT(t)  adds  the 
value  t  as  the  first  element  of  CTUst  and  discards  the  last  element.  The  function  MinCT  delivers  the 
minimum  value  in  CTLIst.  When  the  circuit  is  enabled  all  the  elements  of  CTList  are  initialized  to 
PollESHelloRate. 
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An  End  system  also  niaintains  for  each  circuit  the  variables  currentSuggestedHelloTimer  and  its 
associated  lifetime  currentSuggestedHelloTimerUfetime.  These  are  both  initialized  to  PoUESIHelloRate. 

When  the  circuit  is  enabled  the  Configuration  Timer  is  started  by  setting  the  entryRemainingTime  to 
random  (PollESHelloRate). 

On  Configuration  Timer  expiry  the  following  actions  are  performed: 

a)  SaveCT(currentSuggestedHelloTimer) ; 

b)  Transmit  an  ES  Hello  with  Holding  Time  field  set  to  MinCT  *  HoldingMultiplier; 

c)  Set  entryRemainingTime  to  MinCT  •  random(MinCT  *  0.25).  (The  random  element  ensures 
that  End  systems  do  not  become  synchronized.) 

When  an  End  system  receives  an  IS  Hello  which  contains  a  Suggested  ES  Configuration  Timer,  it  is 
processed  as  follows  (where  suggestedESCT  is  the  value  contained  in  the  option): 

a)  If  suggestedESCT  is  less  than  or  equal  to  currentSuggestedHelloTimer  then  set 
curentSuggestedHelloTimerLifetime  to  the  value  of  the  Holding  Time  field  of  the  IS  Hello; 

b)  If  suggestedESCT  is  less  than  currentSuggestedHelloTimer  then  set 
currentSuggestedHelloTimer  to  suggestedESCT  and  reset  entryRemainingTime  to  the  smaller  of 
its  current  value  and  random(currentSuggestedHelloTimer  *  0.75). 

When  the  currentSuggestedHelloTimerLifetime  expires,  set  the  currentSuggestedHelloTimer  to 
DefaultESHelloTimer. 


8.2      ISO  10030  End  System  to  Intermediate  System  Routing 

The  protocol  used  to  provide  End  System  to  Intermediate  System  routing  in  support  of  the  CONS  (refer 
to  3.6)  shall  be  ISO  10030. 

The  following  agreements  apply  to  the  use  of  ISO  10030: 

a)  A  management  mechanism  capable  of  adding  and  deleting  entries  in  the  Routing  Information 
Base  (RIB)  of  both  SNAREs  and  End  Systems  is  recommended.  When  using  the  management 
mechanism  to  add  an  entry  it  should  not  be  timed  out,  and  the  entry  should  be  write  protected 
from  alteration  by  the  ISO  10030  protocol. 

b)  The  multicast  addresses  corresponding  to  "All  CONS  End  Systems"  and  "All  CONS  SNAREs" 
shall  default  to  the  following  on  IEEE  802.3  and  IEEE  802.4  subnetworks: 

1)  All  CONS  End  Systems  =  01-80-C2-00-00-16 

2)  All  CONS  SNAREs      =  01 -80-C2-00-00-1 7 
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3.3      Intra-Domain  Intermediate  Systems  to  Intermediate  Systems 
Routing 

8.3.1       static  Intra-Domain  Routing 

Intermediate  systems  shall  provide  mechanisms  to  create  and  update  the  required  Routing  Information 
Base. 


8.3.2       Dynamic  Intra-Domain  Routing 

NOTE  -  Defect  reports  upon  the  base  standard  have  been  issued.  See  clause  4  of  this  part  for  further 

Information. 

The  protocol  used  to  provide  Intermediate  System  to  Intermediate  System  routing  In  support  of  the 
CI-NS  (refer  to  clause  3.5)  among  systems  in  a  single  routing  domain  shall  be  ISO  10589. 

The  following  agreements  apply  to  the  use  of  ISO  10589: 

a)  A  management  mechanism  capable  of  configuring  the  Identifier,  Characteristic,  and  Status 
attributes  of  the  managed  objects  of  clause  1 1  shall  be  provided; 

b)  The  implementation  shall  support  a  system  identifier  (ID)  length  of  6  octets  and  shall  use  this 
value  as  a  default. 

8.4      Inter-Domain  Intermediate  Systems  to  Intermediate  Systems 
Routing 

An  Administrative  Authority  shall  detemnlne  the  procedures  and  policies  that  govern  the  exchange  of 
routing  information  with  other  routing  domains. 

Intermediate  systems  shall  provide  management  mechanisms  to  configure  the  required  Inter-domain 
routing  information. 
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9    Procedures  for  OSI  Network  Service/Protocol  Identification 
9.1  General 

The  Protocol  Identifiers  specified  in  ISO  TR  9577  fProtocol  identification  in  the  OSI  Networic  Liiyer^ 
provide  a  basis  from  which  OSI  systems  (tx)th  erxl  systems  and  intermediate  systems)  may  derive  a  set 
of  procedures  for  indicating  which  OSI  protocols  are  used  in  a  particular  instance  of  communication.  As 
such,  these  procedures  are  only  concerned  with  Initial  Protocol  Identifiers  OPIs)  and  Subsequent 
Protocol  Identifiers  (SPis)  that  identify  OSI  protocols  and  pertain  to  the  following  types  of  systems: 

a)  systems  providing/supporting  only  CONS  (using  ISO  8208/8878); 

b)  systems  providing/supporting  only  CLNS  (using  iSO  8473); 

c)  systems  providing/supporting  both  CONS  and  CINS. 

From  this  set  of  definitions,  the  following  possibOities  for  success  (S)  or  feiHure  (F)  of  an  instance  of 
communication  can  be  defined,  as  shown  in  the  table  below: 


Table  1  -  End  Systems  Communications 


Originating 

Destination  End  System  Type 

End  Systea  Type 

A 

B 

c 

A 

S 

F 

s 

B 

P 

S 

s 

C 

s 

S 

s 

9.2     Processing  of  Protocol  Identifiers 

The  usage  of  Protocol  identifiers  in  Network  Protocol  Data  Units  (NPDUs)  depends  on  several  feictors: 

a)  the  OSi  Network  Service  to  be  provided; 

b)  the  protocol  to  be  used  in  providing  this  service; 

c)  the  role  the  protocol  is  to  be  used  in  (per  the  Internal  Organization  of  the  Network  Liiyer); 

d)  the  type  of  sul)network  to  whteh  the  system  is  connected. 
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9.2.1       Originating  NPDUs 

The  use  of  a  particular  OSI  Network  Service  depends  on  tlie  capabilities  of  botli  tlie  origination  and 
destination  end  systems.  It  is  not  tiie  intent  of  this  clause  to  provide  guidelines  on  how  to  n^ke  this 
choice  except  for  simple  obvious  criteria;  rather,  it  is  intended  only  to  provkJe  guklance  on  how  to 
convey  this  choice  to  the  destination  system. 

Where  a  priori  knowledge  exists  in  the  originating  end  system  about  the  capabilities  (with  respect  to  OSI 
Network  Services  available)  of  the  destination  end  system,  it  should  be  used.  This  may  result  in  no 
communication  if  the  two  end  systems  involved  only  provide  Network  Services  of  different  types.  A 
selection  is  required  in  cases  where  both  end  systems  provkJe  boXh  types  of  network  services;  this 
selection  is  conveyed  by  the  use  of  the  IPi  and  SPI  (but  the  selection  process  is  an  implementation 
matter).  Alternatively,  where  a  priori  knowledge  does  not  exist,  then  the  selection  of  a  servtee  to  use  in 
an  instance  of  communication  depends  solely  on  the  capabilities  of  the  originating  end  system  as 
describ>ed  below: 

a)  If  only  CONS-related  protocols  (e.g.,  ISO  8208)  are  available,  then  this  should  be  used  and 
the  Protocol  Identifiers  specified  so  as  to  reflect  the  chosen  protocol  (s)  and  service; 

b)  If  only  CLNS-related  protocols  (e.g.,  ISO  8473)  are  available,  then  this  should  be  used  and 
the  Protocol  Identifiers  specified  so  as  to  reflect  the  chosen  protocol  (s)  and  service; 

c)  If  both  services  are  available,  then  other  criteria  are  used  in  deciding  which  to  use  in  an 
instance  of  communication. 

NOTE  -  The  choice  of  OSI  Network  Service  to  be  used  in  an  instance  of  communication  Is  reflected  in  the 
Network  Service  primitives  issued  by  the  Network  Service  user. 

Once  a  selection  of  Network  Service  has  been  made,  the  use  of  particular  protocols  depend  on,  for 
example,  the  subnetwork  to  which  the  originating  End  System  is  attached.  Some  specific  cases  are 
given  in  Annex  A  of  ISO  TR  9577.  Another  case  involves  use  of  the  Protocol  for  ProvkJing  the 
Connectionless  Network  Service  directly  over  the  Data  Link  Service,  as  given  in  ISO  8473  (e.g..  in  a 
LAN).  In  this  case,  the  IPI  indicates  ISO  8473. 


9.2.2       Destination  System  Processing 

A  system  receiving  an  NPDU  must  first  be  concerned  with  the  protocol  kJentified  by  the  IPI.  ValW  values 
are  given  in  table  2  of  ISO  TR  9577.  If  the  protocol  is  recognized  as  one  supported  by  the  system, 
further  processing  of  the  protocol  is  performed  according  to  the  rules  of  that  protocol.  If  not.  an  en-or  is 
recognized  and  may  be  conveyed  to  the  originating  peer  entity.  With  respect  to  ISO  8208  and  ISO  8473, 
the  following  would  apply  for  such  error  conditions: 

a)  For  ISO  8208.  the  condition  is  classified  as  an  "invalkl  General  Format  Identifier,"  for  which  a 
DIAGNOSTiC  packet  may  be  returned,  if  DIAGNOSTIC  packets  are  not  used  by  the  system,  the 
NPDU  is  discarded  without  any  further  action; 

b)  For  ISO  8473,  the  NPDU  is  discarded  without  any  further  action. 
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Given  acceptance  of  the  protocol  identified  by  the  iPI.  the  system  must  also  detemnine  the  acceptability 
of  the  subsequent  protocols  and  OSi  Network  Service  being  requested.  Use  of  ISO  8473  Implies  CLNS; 
however,  use  of  ISO  8208  can  imply  either  CONS  or  GUMS,  as  identified  by  the  SPI.  In  the  case  of  ISO 
8208,  therefore,  further  processing  is  needed  to  determine  the  acceptability  of  the  requested 
protocol/service.  If  these  are  not  acceptable  (e.g.,  not  supported  by  the  system),  the  call  should  be 
cleared  with  a  diagnostic  code  of  "Connection  Rejection  -  unrecognizable  protocol  identifier  in  user  data" 
(decimal  249). 

NOTE  -  In  ISO  8208,  a  call  may  be  refused  for  reasons  other  than  non-support  of  the  requested  OSI 
Network  Service. 


9.2.3       Further  Processing  in  Originating  End  System 

Further  processing  on  receipt  of  an  NPDU  in  response  to  an  initial  attempt  to  communicate  may  be 
necessary/useful  to  determine  the  success  of  such  an  attempt. 

For  ISO  8473,  when  used  directly  over  the  Data  Unk  Service,  the  success  or  failure  of  an  attempt  to 
communicate  may  not  be  visible/obvious  within  the  Network  l^yer.  On  the  other  hand,  use  of  ISO  8473 
over  ISO  8208  may  provkle,  via  the  diagnostic  code  in  a  received  CI-EAR  INDICATION  packet,  an 
Indication  of  failure  to  communicate  (e.g.,  the  remote  system  does  not  support  Ct-NS). 

When  using  ISO  8208  to  provkJe  the  CONS,  the  diagnostic  code  in  a  received  CLEAR  INDICATION 
packet  may  provide  the  necessary  indication  of  why  a  call  was  refused.in  cases  where  an  ISO  8208  call 
is  refused  with  diagnostic  #249,  it  would  not  be  desirab>le  to  re-attempt  such  calls  with  the  exact  same 
set  of  parameters;  however,  how  the  originating  system  ensures  this  is  a  local  matter. 

In  cases  where  an  originating  system  is  capable  of  supporting  both  OSI  Network  Services,  it  may  wish 
to  re-attempt  communications  using  the  other  mode  of  Network  Service  than  that  initially  attempted. 


9.3     Applicable  Protocol  Identifiers 

The  protocol  identifiers  applicable  to  these  agreements  are  given  in  table  2  and  table  3. 
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Tabie  2  -  IPI  Values 


Bit  Pattern 
87  654321 

Protocol 

00001000 
10000001 
10000010 
10000011 
10000110 
xxOlxxxx 
xxlOxxxx 
OOllxxxx 

CCITT  I.451/Q.931 

ISO  8473  (excluding  the 

inactive  subset) 

ISO  9542 
ISO/IEC  10589 
ISO/IEC  11577 

ISO  8208/CCITT  X.25-Modulo  8 
ISO  8208/CCITT  X.25-Modulo  128 
ISO  8208/CCITT  X.25-GFI  Extension 

Table  3  -  SPI  Values 

Bit  Pattern^ 
87654321 

Protocol 

00000000 
thru 

00111111 
10000001 
10000011 
10000100 
10000110 

ISO  8073  ADDl/CCITT  X.224 
See  table  4.1 

ISO  8473 
ISO/IEC  10589 
ISO  8878/Annex  A 
ISO/IEC  11577 

NOTES 

1    A  null  SPI  value  (e.g.,  no  Call  User  Data  Field  in  an 
ISO  8208/CCITT  X.25  Call  Request /Incoming  Call  packet) 
shall  indicate  ISO  8073/CCITT  X.224. 

When  using  ISO  8208,  values  other  than  one  of  those  listed  in  table  3  are  outside  the  scope  of  these 
agreements. 

10  Migration  Considerations 

This  clause  considers  problems  arising  from  evolving  OSI  standards  and  implementations  based  on 
earlier  versions  of  OSI  standards. 

Until  there  is  widespread  availability  of  1984  X.25  service,  it  will  be  necessary  for  X.400  systems  to  use 
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those  existing  pacl(et-switched  public  data  networl<s  whicli  offer  only  pre-1984  X.25  service.  While  1980 
X.25  does  not  provide  the  CONS  as  defined  by  ISO  8348,  there  is  no  implication  of  non-conformance  to 
these  Agreements  resulting  therefrom  for  systems  using  1980  X.25  to  interchange  data  at  the  Networl< 
Layer,  provided  they  conform  in  all  other  respects. 

This  is  an  exception  to  the  Agreements  for  providing  the  OSI  Networl<  Service,  granted  temporarily  for 
practical  reasons.  This  exception  will  be  removed  when  it  is  deemed  to  be  no  longer  necessary,  in  the 
Judgement  of  the  Wori(shop.  While  this  provision  is  in  effect,  it  provides  an  alternative  method  of  using 
1980  X.25  to  the  provisions  of  6.2. 


11  Use  Of  Priority 

Refer  to  the  Worldng  Implementation  Agreements  document. 

11.1  Introduction 

Refer  to  the  Worldng  Implementation  Agreements  document. 

1 1 .2  Overview 

Refer  to  the  Working  Implementation  Agreements  document. 

12  Security 

Rofor  to  the  Working  Implomontation  Agroonfwnto  document. 


Wf'^fpS^/m  DIS 11577  Network  Uyer  Security  (Protocol  (NtSP) 

tSO/lj^^f ;  II^T?  <l^be^  both  «  oormcaoh  orionted  ^  <>on»eotroeie$$  ^ecwrfty  protocol  that 
be  ysiif  ^^£tt|tiric;tlon  wSh  0$f  Ne^rk  layer  Protocols.  Before  secure  commanication  can  be 
acoQfl^bed, «  $eou%iu»$oMQft  Onband  orodtof  band^      )^  been  e^l^ied  with 
egreemenr  m  ai  aktrlsLtes'associaled  with  this  assodatloa 

Maliasedl  obfects  are  not  yet  epecifiecl  by  tfiis  standard  and  therefore  the  security  doms^n/ado^^^^^ 
mm)i^  $hidl  <ietermiiie  the  procddure^  end  poSclde  £het  govern  this  Infomndtlon  vMt  other  eeotir 

ilSf^iiKiatoryiiari^  by  these  Implementatibn  agreemenle^ 
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To  opUn«s»  dlllGiericy  aivd  a$$isi  i»  mo 


12^4    Protocol  Pata  Unit 

AithouQh  ih9  9tarKiarci  has  thft  op^    ait  typ^en^ 


ondefinfid  (type  Held  lia»     been  aiocated  a  value  in  the  NL^  $ianclard$)'  orM  FIP^  lifflv  one 
Secarty  ch6(^,  ^o  $6C(j«  encapsulated  PDU  $ho«jkl  lie  <^rc^^'^|^'|^^^l$^, 
aftu^n  1$  $1  iQcaT  inatier*  If  shared  kraiwiedsie  oJ  tfeta  overt  1$  required*  $  r 
Id     Ute  sy^m  metiegemerir  10  iiepo^  the  err^^ 

The  Security  Aasodation-tdemica^n  fiald  should  be  iio  «!#e^tliaii^  twenty  ^<0(^ 


its    Furictlonal  SecitrHy  Saquanoa 

0  Acceaecontrot  1$  Impiemented  uain^  iabete,  the  label  fundion  IsM 
l^mction.  If  conlidentiiality  has  also  been  sheeted*  then  that  function  Is 


If  I(ite9^  mi  oonf id^^tia%  have  t>aen  selecidd,  fhen  the  Integrity  Hinctlon  la  patfomiad 

iKafidenllaly  iftjncficBi: 


13  Conformance 

Refer  to  the  Working  Implementation  Agreements  document. 
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Annex  A  (informative)  
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Foreword 

This  part  of  the  Stable  ImplemerTtation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(l_LSIG)  of  the  Open  Systems  Environment  Implementors'  Wort<shop  (OIW).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  4  -  Transport 


0  Introduction 

These  agreements  support  the  integration  of  l^s,  pacl<et  networks,  and  other  WANs  with  the  smallest 
possible  set  of  mandatory  protocol  sets,  in  accordance  with  the  other  agreements  already  reached.  Nothing 
here  shall  preclude  vendors  from  implementing  protocol  suites  in  addition  to  the  ones  descrit>ed  in  this 
document. 


1  Scope 

This  part  presents  agreements  for  providing  the  OSI  Transport  layer  services  over  both  connection  mode 
and  connectionless  mode  services. 


2    Normative  References 


2.1  CCITT 

[1]      Recommendation  X.214  (Blue  Book,  1988),  Transport  Service  Definition  for  Open  Systems 
Interconnection  for  CCITT  Applications. 

[2]      Recommendation  X.224  (Blue  Book,  1988),  Transport  Protocol  Specification  for  Open  Systems 
Interconnection  for  CCITT  Applications. 


2.2  ISO 

[3]  ISO  8072,  Information  processing  systems  -  Open  systems  interconnection  -  Transport  sen/ice 
defintion. 

[4]  ISO  8072  Addendum  1,  Information  processing  systems  -  Open  systems  interconnection  - 
Addendum  1:  Transport  service  definition  -  Connectionless-mode  transmission. 

[5]  ISO  8073  Edition  2,  Information  processing  systems  -  Open  systems  interconnection  -  Connection 
oriented  transport  protocol  specification. 

[6]  ISO  8073  Addendum  1,  Information  processing  systems  -  Open  systems  interconnection  - 
Connection  oriented  transjDort  protocol  specification  -  Addendum  1:  Network  connection 
management  subprotocol. 

[7]  ISO  8073  Addendum  2,  Information  processing  systems  -  Open  systems  interconnection  - 
Connection  oriented  transport  protocol  specification  -  Addendum  2:  Class  four  operation  over 
connectionless  network  sen/ice. 

[8]       ISO  8602,  Infonnation  processing  systems  -  Open  systems  interconnection  -  Protocol  for  providing 
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3  Status 

Completed  December  1990. 


4  Errata 


NOTE  -  This  clause  may  contain  'defect  reporf  and  resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  material  applies. 


5    Provision  of  Connection  Mode  Transport  Service 

Three  connection  mode  p>rotocol  classes  have  been  Identified  for  implementation.  Transport  classes  0, 2  and 
4  of  X.224  (1988)^  have  been  endorsed  for  use  over  CONS.  Only  Transport  Class  4  of  ISO  8073/Add.  2  ^ 
has  been  endorsed  for  use  over  CLNS.  The  following  dass  combinations  are  endorsed  for  CONS:  (0),  (0,2) 
or  (0.2.4). 


5.1      Transport  Class  4 


5.1.1       Transport  Class  4  Overview 

Transport  Class  4  Is  mandatory  for  communication  between  systems  using  the  OSI  CLNS  and  may  also  be 
used  for  systems  using  the  OSI  CONS  (e.g..  a  private  I^HS,  etc.). 


PART  4  -  TRANSPORT 

the  connectionless-mode  transport  sen/Ice. 


'  Where  a  CR  TPDU  proposing  Oass  2  or  4  is  initiated,  Qass  0  shall  be  expllcitiy  indicated  as  an 
alternative  class  except  If  there  is  already  one  (or  several)  transport  connection(s)  assigned  to  the 
network  connection  (multiplexing  being  possible). 

'  In  general,  references  to  ISO  8073  In  ISO  8073/Add.  2  should  be  interpreted  as  applying  to  X.224 
(1988):  however,  the  reference  to  Qause  14.6.a  In  Oause  14  of  ISO  8073/Add.  2  should  be 
Interpreted  as  a  reference  to  Qause  14.5.a  of  X.224(1988). 
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5.1.2       Protocol  Agreements 

A  disconnect  request  shall  be  Issued  In  response  to  a  connect  request  when  the  maximum  number  of 
Transport  connections  Is  reached  or  exceeded. 


5.1.2.1        General  Rules 

The  rules  are  as  follows: 

a)  All  implementations  shall  request  'use  of  extended  formats"  in  the  CR  TPDU.  Implementations 
shall  accept  the  'use  of  extended  formats'  In  the  CC  TPDU  if  it  was  proposed  in  the  CR  TPDU. 
Implementations  shall  accept  'use  of  norrr^  formats'  if  it  was  proposed  in  the  CR  TPDU; 

b)  Negotiation  of  protection  is  outside  the  scope  of  these  agreements,  if  negotiation  of  protection 
Is  not  supported,  receipt  of  the  protection  parameters  in  CR  TPDU  and  CC  TPDU  shall  be  ignored; 

c)  Implementations  shall  be  capable  of  proposing  and  accepting  the  non-use  of  checlcsums; 
N07£ » Soe  clause  eM  tor      Jnlorma^  on  oheck3<.mi3  vvNn  Hie  ittmipott  Pf<Aoac\  and  IN  Ttampod 

d)  Use  of  the  acknowledgment  time  parameter  is  optional.  If  an  implementation  is  operating  any 
policy  which  delays  the  transmission  of  AK  TPDUs,  the  maximum  amount  of  time  by  which  a  single 
AK  TPDU  may  be  delayed  shiall  be  indicated  to  the  peer  Transport  service  provider  using  the 
acknowledgment  time  parameter.  The  value  transmitted  should  be  expressed  in  units  of  milliseconds 
and  rounded  up  to  the  nearest  whole  millisecond; 

e)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  throughput,"  'residual  error  rate,"  "priority,"  and  "transit  delay"  in  the  CR 
and  CC  TPDUs  shall  be  ignored; 

f)  It  is  recommended  that  implementations  not  send  user  data  in  the  CR  TPDU  or  the  CC  TPDU. 
The  disposition  of  any  user  data  received  in  a  CR  TPDU  or  CC  TPDU  is  implementation  dependent; 

g)  It  Is  recommended  that  Implementations  not  send  user  data  in  the  OR  TPDU.  The  disposition 
of  any  user  data  received  In  a  OR  TPDU  is  Implementation  dependent; 

h)  An  unknown  parameter  in  any  received  CR  TPDU  shall  be  ignored; 

I)  A  Transport  entity  shall  accept  a  DR  TPDU  and  a  corresponding  DC  TPDU  with  or  without  a 
checksum  in  response  to  a  CR  or  CC  TPDU; 
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j)  Transmitted  DR  TPDUs  shall  carry  a  disconnect  reason  code  which  pertains  to  the  actual  cause 
of  the  disconnect.  A  DR  TPDU  may  carry  a  reason  code  of  "0"  (unspecified)  if  an  appropriate  reason 
code  Is  not  defined; 

k)  Known  parameters  with  valid  lengths  but  with  Invalid  values  In  a  CR  TPDU  shall  be  handled  as 
follows: 

1)  Parameter:  2)  Action: 


a) 

TSAP  id 

a) 

b) 

TPDU  size 

b) 

c) 

Version 

c) 

d) 

Checksum 

d) 

e)  Alternate  Protocol  Qasses    e)  Protocol  Error 


I)  Unrecognized  or  not  applicable  bits  of  the  Additional  Options  parameter  shall  be  ignored. 

m)  It  is  recommended  that  the  capability  of  request  acknowledgments  be  supported  and  proposed 
in  CR  TPDUs.  If  request  acknowledgments  are  supported,  then  if  the  implementation  delays 
acknowledgments  it  shall: 

1)  request  use  of  request  acknowledgments  in  the  CR  TPDU; 

2)  accept  the  use  of  request  acknowledgments  in  the  CC  TPDU  if  it  was  proposed  in  the 
CR  TPDU. 

n)  It  is  recommended  tiiat  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

o)  It  is  recommended  that  inactivity  timer  values  be  exchanged  during  connection  establishment. 
This  may  be  mandatory  in  the  future.  If  the  "exchange  of  inactivity  timers"  capability  is  supported, 
the  implementation  shall  send  its  minimum  inactivity  timer  in  the  CR  TPDU.  If  a  CR  TPDU  is  received 
with  this  timer  value  and  the  capability  is  supported,  the  responding  CC  TPDU  shall  contain  the 
inactivity  time. 

If  the  inactivity  time  is  received  and  the  capability  is  supported,  the  following  shall  be  used  as  an  upper 
t}ound  for  W: 


Ir/N  >  W        N  >.  2 
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5.1.2.2 


Transport  Class  4  Service  Access  Points  or  Selectors 


If  present,  the  TSAP  Id.  field  In  the  CR  and  CC  TPDUs  shall  be  enccxied  as  a  variable  length  field  and  will 
be  interpreted  as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets. 


It  is  recommended  that  the  value  used  for  the  retransmission  timer  be  based  upon  the  round-trip  delay 
experienced  on  a  transport  connection.  The  implementation  should  maintain,  and  continually  update,  an 
estimate  of  the  round-trip  delay  for  the  TC.  From  this  estimate,  a  value  for  the  retransmission  timer  is 
calculated  each  time  it  is  started.  Example  techniques  for  maintaining  the  estimate  and  calculating  the 
retransmission  timer  are  described  t>elow.  Example  1  represents  a  simple  retransmission  strategy  and 
example  2  is  particularly  suitable  for  networks  subject  to  high  traffic  loads. 


The  value  of  the  retransmission  timer  may  be  calculated  according  to  the  following  formula: 
T1  < —  kE  +  AR. 

In  this  formula,  E  Is  the  current  estimate  of  the  round-trip  delay  on  the  transport  connection,  AR  is  the  value 
of  the  acknowledgment  time  parameter  received  from  the  remote  transport  service  provider  during 
connection  estatslishment,  and  k  Is  some  locally  administered  factor. 

A  value  for  k  should  be  chosen  to  keep  the  retransmission  timer  sufficiently  small  such  that  lost  TPDUs  will 
be  detected  quickly,  but  not  so  small  that  false  alarms  are  generated  causing  unnecessary  retransmission. 

The  value  of  E  may  be  calculated  using  an  exponentially  weighted  average  based  upon  regular  sampling 
of  the  interval  between  transmitting  a  TPDU  and  receiving  the  corresponding  acknowledgment.  Samples  are 
taken  by  recording  the  time  of  day  when  a  TPDU  requiring  acknowledgment  Is  transmitted  and  calculating 
the  difference  between  this  and  the  time  of  day  when  the  corresponding  acknowledgment  is  received.  New 
samples  are  incorporated  with  the  existing  average  according  to  the  following  formula: 

E  <_  E  +  (1  -  a)iS  -  E). 

In  this  formula,  S  is  the  new  sample  and  a  is  a  parameter  which  can  be  set  to  some  value  between  0  and 
1 .  The  value  chosen  for  a  determines  the  relative  weighting  placed  upon  the  current  estimate  and  the  new 
sample.  A  large  value  of  «  weights  the  old  estimate  more  heavily  causing  it  to  respond  only  slowly  to 
variations  in  the  round-trip  delay.  A  small  value  weights  the  new  sample  more  heavily  causing  a  quick 
response  to  variations.  (Note  that  setting  a  to  1  will  effectively  disable  the  algorithm  and  result  in  a  constant 
value  for  E,  being  that  of  the  initial  seed.) 

If  a  is  set  to  1  -2  "  for  some  value  of  n,  the  update  can  be  reduced  to  a  subtract  and  shift  as  shown  below: 
E  < —  E  +  2  "  (S  -  E). 

When  sampling,  if  an  AK  TPDU  is  received  which  acknowledges  multiple  DT  TPDUs,  only  a  single  sample 
should  be  taken  being  the  round-trip  delay  experienced  by  the  most  recently  transmitted  DT  TPDU.  This 


5.1.2.3 


Retransmission  Timer 


Examole  1 
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attempts  to  minimize  in  the  sampie  any  deiay  caused  by  the  remote  transport  service  provider  withholding 
AKTPDUs. 

As  networl(  ioad  increases,  the  variat>ility  of  round-trip  delay  also  increases.  In  environments  where  load 
fluctuates  widely,  it  is  therefore  useful  to  estimate  the  variability  of  round-trip  delay  measurements  and  use 
this  estimate  in  the  calculation  of  retransmission  timer  values.  An  estimate  of  the  variability  of  round-trip 
deiay  measurements  can  be  efficiently  calculated  as  an  exponentially  weighted  average  of  the  differences 
between  round-trip  delay  measurements  and  the  average  round-trip  delay.  This  represents  the  mean 
deviation  of  the  round-trip  delays,  which  is  a  useful  approximation  of  the  standard  deviation  and  can  be 
much  more  efficiently  computed.  The  formula  is 

D  <-D  +  (t -a)(|S-E| -D) 

where  O  is  the  estimate  of  variability  in  round-trip  delays.  S.  E,  and  a  are  as  defined  for  the  preceding 
formula.  As  t)efore  the  value  of  a  must  be  between  0  and  1  and  the  choice  of  a  value  of  1  -  2"^  allows  for 
efficient  update  of  the  average.  The  value  of  a  for  the  variability  estimation,  though,  does  not  need  to  be  the 
same  as  that  used  for  the  round-trip  delay  estimate.  A  smaller  value  for  a  is  useful  in  the  variability  estimation 
to  cause  a  more  rapid  response  to  changes  in  round-trip  delays.  D  can  then  be  used  to  calculate 
retransmission  timer  values  according  to  the  formula: 

T1  <-  E  +  AR  +  kD 

wfiere  T1  is  the  retransmission  timer  value,  E  is  the  estimated  average  round-trip  delay,  AR  is  the  value  of 
the  acknowledgment  timer  parameter  received  from  the  remote  transport  sen/ice  provider  during  connection 
establishment,  and  k\sa  locally  administered  factor.  Since  D  approximates  the  standard  deviation  of  the 
round-trip  delays,  but  is  greater  than  or  equal  to  the  standard  deviation,  round-trip  delays  within  k  standard 
deviattons  of  the  mean  would  be  accounted  for  by  the  retransmission  timer  value  (e.g.,  =  2.  if  round-trip 
delays  were  normally  distributed,  would  account  for  95%  of  the  variability). 

Round-trip  time  measurements  based  on  acknowledgment  of  any  retransmitted  data  should  not  be  used  to 
update  the  round-trip  delay  estimate  or  the  estimate  of  variability.  Such  measurements  are  not  reliable  since 
it  is  ambiguous  which  transmission  of  the  data  is  being  acknowledged. 

One  strategy  for  handling  a  retransmission  timeout  is  to  retransmit  the  PDU  and  reset  the  timer  with  a  value 
that  is  twice  the  previous  value.  In  this  case,  a  new  roundtrip  delay  estimate  and  estimate  of  variability 
shouM  be  calculated  only  when  an  acknowledgment  of  data  is  received  where  none  of  the  acknowledged 
data  has  been  retransmitted.  This  calculation  uses  the  new  round-trip  delay  measurement  and  the  last 
estimate  before  the  retransmission  timeout(s). 


5.1.2.4        Keep-Alive  Function 

The  Class  4  protocol  detects  a  failed  Transport  connection  by  use  of  an  "inactivity  timer."  This  timer  is  reset 
each  time  a  TPDU  is  received  on  a  connection.  If  the  timer  ever  expires,  the  connection  is  terminated. 

The  Qass  4  protocol  maintains  an  kiie  connection  by  periodically  transmitting  an  AK  TPDU  upon  expiration 
of  the  "window  timer."  Thus,  in  a  simple  implementation,  the  interval  of  one  transport  entity's  window  timer 
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must  be  less  than  that  of  its  peer's  inactivity  timer,  and  vice  versa.  The  following  agreements  pennit 
communicating  transport  entities  to  maintain  an  idle  connection  without  shared  information  about  timer 
values: 


a)  In  accordance  with  ISO  8073/X.224,  Gause  12.2.3.9.a,  all  Implementations  must  respond  to  the 
receipt  of  a  duplicate  AK  TPDU  not  containing  FCC  by  transmitting  an  AK  TPDU  containing  the  How 
control  confirmation"  parameter; 

b)  Implementations  must  always  transmit  duplicate  AK  TPDUs  without  FCC  on  expiration  of  the 
local  window  timer  (see  ISO  8073/X.224,  Gause  12.2.3.8.1).  Receipt  of  this  TPDU  by  the  remote 
Transport  entity  will  cause  It  to  respond  with  an  AK  TPDU  containing  the  How  control  confirmation" 
parameter.  When  this  is  received  by  the  local  transport  entity,  it  will  reset  its  Inactivity  timer.  See 
figure  1; 

c)  It  is  a  local  matter  for  an  implementation  to  set  the  intervals  of  its  timers  to  appropriate  relative 
values.  Specificaily: 

1)  The  window  timer  must  be  greater  than  the  round-trip  delay.  See  5  1.2.3; 

2)  The  inactivity  timer  must  be  greater  than  two  times  the  window  timer;  and  should 
normally  be  an  even  greater  multiple  if  the  Transport  connection  is  to  be  resilient  to  the  loss 
of  an  AK  TPDU. 


A  duplicate  AK  TPDU  (see  figure  1)  is  one  which  contains  the  same  values  for  YR-TU-NR,  credit,  and 
subsequence  number  as  the  previous  AK  TPDU  transmitted.  A  duplicate  AK  TPDU  does  not  acl<nowiedge 
any  new  data,  nor  does  it  change  the  credit  window. 


reset 


reset 


expi  re 


expi re 


expire 


Figure  1  -  AK  exchange  on  idle  connection. 
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5.1.2.5        Congestion  Avoidance  Policies 

This  clause  defines  both  mandatory  and  optional  requirements  relating  to  avoiding  congestion  In  OSI 
networks  and  recovering  from  it  when  it  Is  experienced.  The  mandatory  requirements  specify  a  minimum 
approach  to  congestion  avokJance/recovery  which  can  be  tuned  based  upon  the  specific  requirements  of 
the  network.  The  optional  requirements  specify  a  dynamic  window  sizing  scheme  which,  If  Implemented,  will 
contribute  further  to  the  avokJance  of  congestion  In  the  network. 

Mandatory  Requirements  are  as  follows: 

a)  A  maximum  size  for  the  "receive  credit  window,"  the  value  of  which  is  locally  configurable,  should 
be  provkJed.  A  "receive  credit  window"  reflects  the  number  of  credits  sent  by  a  Transport  entity  for 
a  Transport  connection.  The  maximum  size  of  the  "receive  credit  window"  shall  be  referred  to  as 
WR,; 

b)  A  maximum  size  for  the  "sending  credit  window,"  the  value  of  which  is  locally  configurable,  shall 
be  provkJed.  A  "sending  credit  window"  reflects  the  number  of  data  TPDUs  that  a  Transport  entity 
is  willing  to  send  on  a  Transport  connection.  The  maximum  size  of  the  "sending  credit  window"  shall 
be  referred  to  as  WS^  As  specified  in  ISO  8073,  the  "sending  credit  window"  shall  also  be  less  than 
or  equal  to  the  remote  "receive  credit  window"  as  conveyed  in  the  last  CDT  field; 

c)  It  is  strongly  recommended  that  an  implementation  use  a  retransmission  timer  per  Transport 
connection.  If,  upon  expiration  of  the  retransmission  timer,  an  implementation  allows  more  than  "1" 
TPDU  to  be  transmitted  a  means  to  locally  adjust  the  maximum  number  shall  be  provided; 

d)  All  implementations  shall  have  the  capability  of  operating  without  delaying  ACKs  of  data  TDPUs 
received  in-sequence  (i.e.,  A,^  essentially  equals  zero).  If  an  implementation  optionally  chooses  to 
explicitly  delay  ACKs,  a  means  to  locally  adjust  A^  shall  be  provided. 

Optional  Requirements  are  as  follows: 

For  systems  implementing  the  dynamic  window  sizing  scheme  the  following  rules  apply  as  described  below: 

1.  RECEIVING  TRANSPORT  ENTITY  (RTE)  RULES: 

a)  Rule  1  -  Initialization  of  Window: 

1)  The  initial  value  of  WR  (known  as  WRq)  shall  have  a  locally  configurable  upper  bound. 
This  window  is  sent  to  the  sending  transport  entity  (STE)  in  the  next  CDT  field  transmitted: 

a)  Rule  2  -  Required  Sampling  Period: 

1)  All  PTEs  shall  maintain  a  fixed  value  for  WR  until  the  next  2WR  DT 
TPDU  arrive  since  the  last  CDT  field  was  transmitted  by  the  RTE; 

b)  Rule  3  -  Required  Counting  of  Received  TPDUs  in  a  Sampling  Period: 

1)  All  PTEs  shall  maintain  a  count,  N,  equal  to  the  total  number  of  TPDUs 
received  and  a  count,  NC,  equal  to  the  total  number  of  TPDUs  received 
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which  had  the  CE  Rag  set.  All  types  of  TPDUs  are  Included  In  the  counts 
for  N  and  NC,  not  just  DT  TPDUs; 

c)  Rule  4  -  Required  Action  upon  the  end  of  a  Sampling  Period:  All  RTEs  shall  take 
the  following  actions  at  the  end  of  each  sampling  period: 

1)  If  the  count  NC  Is  less  than  50  percent  of  the  count  N,  the  RTE  shall 
Increase  WR  by  adding  1  up  to  a  maximum,  WR^,  (that  is  tsased  on  the 
local  buffer  management  policy);  otherwise,  It  shall  decrease  WR  by 
multiplying  by  0.875  (a  minimum  of  1); 

2)  Reset  N  and  NC  to  zero; 

3)  Transmit  the  new  window  WR  in  the  next  CDT  field  sent  to  the  sending 
transport  entity; 

2)  SENDING  TRANSPORT  ENTITY  (STE)  RULES: 

a)  Rule  1:       Initialization  of  Window: 

1)  All  STEs  shall  maintain  a  sending  window  size  (WS).  Initially  and  also 
as  long  as  there  is  no  loss,  WS  is  set  equal  to  the  receiving  window  value 
WR  received  from  the  remote  RTE  in  the  last  CDT  field; 

b)  Rule  2:       Required  Action  on  a  Timeout; 

1)  All  STEs  shall  reset  WS  to  one  when  the  retransmissions  timer  expires 
and  indicates  a  lost  TPDU.  WS  now  limits  the  numljer  of  DT  TPDUs  that 
may  be  transmitted  or  retransmitted  without  further  acknowledgments; 

c)  Rule  3:       Required  Counting  of  Acknowledged  TPDU: 

1)  All  STEs  shall  maintain  a  count,  ACKRCVD  of  the  number  of  DT  TPDUs 
acknowledged,  by  the  RTE,  since  WS  was  last  adjusted.  Therefore  each 
time  WS  is  adjusted,  the  count  ACKRCVD  shall  be  reset  to  zero; 

d)  Rule  4:       Increase  Window  Policy: 

1)  All  STEs  shall  increase  WS  by  one  each  time  ACKRCVD  is  equal  to  or 
greater  than  the  current  value  of  WS,  unless  WS  exceeds  the  window 
permitted  by  the  remote  RTE. 


5.1.2.6        Use  Of  Priority 

(Refer  to  the  Working  Implementation  Agreements). 
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5.2.1  Transport  Class  0  Overview 

Transport  Class  0  over  X.25  Is  rnarxJatory  (see  X.400)  for  use  In  communicating  with  public  MHS  systems 
operating  in  accordance  with  the  CCITT  X.400  series  recommendations.  The  purpose  of  the  agreements 
concerning  Transport  Qass  0  Is  to  allow  connection  to  these  public  services.  Transport  Qass  0  over  X.25 
can  also  be  used  In  communicating  between  PRMDs  (this  choice  is  prevalent  outside  North  America). 

5.2.2  Protocol  Agreements 

5.2.2.1  General  Rules 

Transport  Class  0  agreements  are  as  follows: 

a)  The  Error  (ER)  TPDU  may  t>e  used  at  any  time  and  upon  receipt  requires  that  the  recipient 
disconnect  the  network  connection,  and  by  extension  the  transport  connection; 

b)  The  allowed  values  for  the  maximum  TPDU  size  are  128,  256,  512,  1024,  and  2048; 

c)  The  Class  0  protocol  does  not  support  multiplexing.  At  any  instant,  one  Transport  corresponds 
to  one  Network  connection; 

d)  It  is  recommended  that  the  optional  timers  TSl  and  TS2,  if  implemented,  be  settable  by  local 
system  management.  Values  In  the  order  of  minutes  should  be  supported; 

e)  An  unlimited  TSDU  length  must  t>e  supported. 

f)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

5.2.2.2  Transport  Class  0  Service  Access  Points 

For  communicating  with  public  MHS  systems,  section  5  of  X.410  specifies  the  use  and  format  of  TSAP 
identifiers. 

5.2.3  Rules  for  Negotiation 

The  rules  for  class  negotiation  shall  be  used. 
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5.3.1  Transport  Class  2  Overview 

Transport  Class  2  is  applicable  in  OSI  end  systems  which  provide  the  Connection-nrKxle  Network  Service. 

5.3.2  Protocol  Agreements 

Transport  Class  2  agreements  follow: 

a)  The  values  of  the  TSI  and  TS2  timers  shall  be  configurable.  The  recommended  timer  values  are: 

1)  TS1:  60  seconds; 

2)  TS2:  60  seconds; 

b)  If  present,  the  TSAP-id  field  in  the  CR  and  CC  TPDUs  shall  be  encoded  as  a  variable  length  field 
and  will  be  interpreted  as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets; 

c)  The  rules  for  class  negotiation  shall  be  used; 

d)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  "throughput,"  "residual  error  rate."  "priority,"  and  transit  delay"  in  the  CR 
and  CC  TPDU  shall  be  ignored. 

NOTE  -  If  Class  0  is  indicated  in  the  Alternative  Protocol  Class  field  and  QoS  parameters  are  conveyed  and 
the  responding  end  system  chooses  Class  0,  then  the  QoS  parameters  have  been  ignored  by  the  respofKlIng 
system. 

e)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

6    Provision  of  Connectionless  Transport  Service 

ISO  8072/Add.  2  is  the  Transport  Service  Definition  covering  Connectionless-mode  Transmission.  ISO  8602 
is  the  Protocol  for  providing  the  Connectionless-Mode  Transport  Service. 
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6.1      Connectionless  Transport  Overview 

When  providing  the  connectionless  Transport  Service,  the  protocoi  shail  be  implemented  as  specified  in  ISO 
8602. 


6.2      Protocol  Agreements 


6.2.1       General  Rules 

The  connectionless  Transport  protocol  is  a  relatively  simple  protocol  providing  little  opportunity  for 
conflicting  interpretations.  A  few  relevant  agreements  follow: 

a)  The  optional  elements  of  procedure  for  use  of  CLTS  over  CONS  (i.e.,  clause  6.3  of  ISO  8602) 
will  not  be  supported; 

b)  A  Unitdata  TPDU  that  is  received  that  contains  a  protocol  error  or  an  unknown  destination  TSAP 
ID  shall  be  discarded. 


6.2.2       Connectionless  Transport  Service  Access  Points  or  Selectors 

The  TSAP  selector  field  in  the  UD  TPDU  shall  be  encoded  as  a  variable  length  field  and  will  be  interpreted 
as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets. 


7    Transport  Protocol  Identification 

The  absence  of  Call  User  Data  (CUD)  in  an  X.25/iSO  8208  Call  Request/Incoming  Call  packet  indicates  the 
operation  of  ISO  8073/CCITT  X.224. 

Protocol  Identification  TPDU  values  applicable  to  these  agreements  are  given  in  table  1 .  These  TPDUs,  when 
used,  are  conveyed  as  N-connect  user  data. 


Table  1  -  Protocol  Identification  TPDU  Values 


TPDU  Value 

Protocol 

03    01    01    00  * 
(see  note  1) 
03    01    02    00  ** 
(see  note  2) 

ISO  8073/Add.  1 
ISO  8602 

NOTES 
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1  Corresponds  to  an  ISO  8073/Add.  1  UN-TPDU  and  a  X.224  Annex  B  PI-TPDU. 

2  Corresponds  to  an  ISO  8073/Add.  1  UN-TPDU. 
The  foilowing  agreements  apply: 

a)  Any  additional  TPDU,  which  follows  (by  concatenation)  a  Protocol  Identification  TPDU  shall  be 
ignored  if  ISO  8073/Add.  1  is  not  supported; 

b)  When  using  ISO  8208,  usage  of  a  Protocol  Identification  TPDU  not  corresponding  to  those  listed 
in  table  1  is  outside  the  scope  of  these  agreements. 


8  Security 

Rofor  to  the  Working  impiomontation  Agroomonts  document. 


a*1     ISO/IEC 10736  Transport  Layer  Security  Protocol  (TtSf*) 

tSO/lEO  1073^  de$Of  lbe$  both  a  ijonnectiofi  oflente^t  and  cortneotk»ites$  $ecurity  protocol  thait  oan  be  «$ed 
h  con^dioni  with  0$t  Transport  Layer  Prctocols  ^SO/fEO  8070  and  ISO/IEO  6602).  Before  mcisre 
wevmtit^\m  ^  b^  aocompll$ii0(i,  «  $mx^  moo^0m  ^  or  out  of  band)  $Ni  bim 
l^bli^ied  with  wgremmit  on  ai  attHbifte&  asscK^ated  with  Hils  assodia^n. 

Mane^^  <^ects  are  not  ^peoiBd  by  this  ^^afxlaid  and  ^refore  ^e  security  domaln/acirTilnistratiye 
mithcity       determir^  th9  procedure  arid  poiici$$  thair  9cvem  ihi$^  informstlon      ^ther  i^iffly 

M  mandatory  functions  are  supported  by  tliese  im(^ementatk}n  agre®T)enls» 


ZJZ  Services 

U  mifm  oontrci  service  ^  $^ectect  mS  the  Idbeie  meohanism  1$  used,  ^n  Integrity  «hdlt  also  seTected. 

Hie  Tim^att  Pase  4)  k^ior  propose  the  nornise  ol  <^$ck$um$  if  TL$P  1$  aiso  Invc^ed  v^h 
ftsrwiectiiDn  ptegrfty  selected  (as  this  would  be  redufidantftintctionallty).  Hie  Integrity  mechanfem  selected 
lhag  i)e  one  of  the  reoommenc^  algorithms  {e  signed  M0$  or  $H4  lor  publlo  key  $yeter»$  or  DES  MAO 
for  secret  l«ey  sy^ems  to  name  a  (ewi)  In  pwt  12  (OS  Seciaty)  of  tf»se  agrewnents  or  a  private 
elQorihm  ihat  both  oomtmloating  parties  have  agreed  to  i^se. 


13 


PART  4  -  TRANSPORT 


December  1992  (Stable) 


a,3  Mechanisms 

To  QplimlzQ  Al&rtcy  3(Kt        In  tha  inieropdr^bii^    $$Ctir$  Impl^m^rM^ons^  It  j$  useful  10  $PQ(% 

m^ip$iMx\m  format      Intcludrnc  -   required,  thi^r  length,  end  Ofili^^^  A  s^t  <^  appBc^W© 

^led  within  ^  ImpiementatiDn  Agreememsto  Insur^^ 


a.4     Protocol  Constraints 

i^^lthDt^  tim  9tajnd£»idl  has  ^  <^)^n  dl  ai  t^peHlengthAcaJ^  0lv)  itelds  bi^ng  In  any  orcfer*  l^r  ^SB^mpf* 
th0  encd|)«ule[tloii  ^rmed  ctepKntfd  in  the  ^ncM  $hdll  la«^  t}$ed.  If  }lie  Wliekid  a^  not  miiM^ 
fieid  has  nol  been  allocated  a  va^  fin  the  TtSP  S!i»idard):»  or  the  $E  WDtU  one^of  ,the  JL^P 
Security  Cheeks,  the  secure  encapsulated  P0U  should  t)«  discarded.  The  reponih^of  th1$  situation  isiito^ 
matter.  If  ^red  knowledge  of  Hi^  event  is  required^  a  pos^ble  tedmlque  would  be  to  use  the  sys^m 
mana^ment  to  report  the  error, 

The  Secutty^  A^sociation-ldenttRcaUon  Held  should  fee  m  more  than  20  o<^9. 


8.5     Functional  Security  Seciu^nce  Ordering 

If  Access  control  is  In^etneraed  using  labels^  the  lab^  lynctian  Is  first  applied  foUowed  by  the  6iNp1ty 
function.  If  oonfldentyity  has  also  been  selected,  then  that  fanctiOh  Is  petfomed  after  the  Integrity  function, 

if  Integrity  and  oonfldenflality  have  been  selected,  the  Integrity  itinctiort  Is  perfonhed  before  thecon^entiellty 
functions 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Upper  Layers  Special  Interest 
Group  (ULSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OiW).  The  charter  for  the 
OIW  is  located  in  the  Procedures  Manual. 

The  text  in  this  part  has  been  approved  by  the  Plenary  of  the  OIW.  This  part  replaces  the  previously 
existing  part  on  the  Upper  Layers. 

Annex  B  is  for  infornr>ation  purposes  only.  Annex  A  forms  an  integral  part  of  these  Implementor 
Agreements. 

Future  changes  and  additions  to  these  Implementor  Agreements  will  be  put)lished  as  change  pages. 
Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as  shaded. 
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Part  5  -  Upper  Layers 


0  Introduction 

In  this  portion  of  the  Implementors'  Agreements,  the  Upper  Layers  SiG  Is  prinfiarily  concerned  with 
providing  Implementation  agreements  for  ACSE,  ROSE,  RTSE.  and  the  Presentation  and  Session  layers, 
so  that  systems  Implemented  according  to  these  agreements  can  successfully  interoperate. 


1  Scope 

The  agreements  In  this  part  apply  to  all  ASE  agreements  In  this  document.  Each  ASE  SiG  chooses 
which  protocols,  functional  units,  application  contexts,  and  parameters  it  requires.  These  must  be  listed 
In  the  "Specific  ASE  Requirements"  clause  of  this  part. 


2    Normative  References 


2.1      Session  Layer 

[1]      ISO  8326: 1987  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Connection  Oriented  Session  Service  Definition. 

[2]       ISO  8327:  1987  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Connection  Oriented  Session  Protocol  Specification. 

[31      ISO/IEC  JTC1  /SC21  N2494,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Connection  Oriented  Session  Service  Deflnltlon-AD  2  to  ISO  8326  to  Incorporate 
Unlimited  User  Data. 

[A]      ISO/IEC  JTC1/SC21  N2495,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Connection  Oriented  Session  Protocol  Specification  -AD  2  to  ISO  8327  to  Incorporate 
Unlimited  User  Data. 

[5]       iS0/AD3  8326,  Information  Processing  Systems  -  Open  Systems  Interconnection-Session 
Sen/ice  Definition:  Addendum  3  Covering  Connectionless-Mode  Session  Service. 

[6]      ISO/IS  9548,  Information  Processing  Systems  -  Open  Systems  Interconnection-Connectionless 
Session  Protocol  to  Provide  the  Connectionless-Mode  Session  Service. 
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2.2      Presentation  Layer 

[7J       ISO  8822:  1988  (ISO/IEC  JTCl  /SC21  N2335).  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Connection-Oriented  Presentation  Sen/ice  Definition. 

[8]       ISO  8823:  1988  (ISO/IEC  JTCl  /SC21  N2336).  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Connection  Oriented  Presentation  Protocol  Specification. 

[9]       ISO  8824:  1990  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Abstract  Syntax  Notation  One  (ASN.  1). 

[10]     ISO  8825:  1990  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1). 

[11]     IS0/DAD1  8822:  1989-02-15(e)  (ISO/IEC  JTC1/SC21  N  3171).  Information  Processing  Systems  - 
Open  Systems  Interconnection  -  Presentation  Sen/ice  Definition:  Draft  Addendum  1  Covering 
Connectionless-Mode  Presentation  Sen/ice. 

[12]     ISO/IS  9576:  1989-02-25  5(E)  (ISO/IEC  JTC1/SC21  N  3172).  Information  Processing  Systems  - 
Open  Systems  Interconnection  -  Connectionless  Presentation  Protocol  to  Provide  ttie 
Connectionless-Mode  Presentation  Sen/ice. 


2.3     Application  Layer 

[13]     ISO/DP  9545.  ISO/TC97/SC21/N1743.  July  24,  1987.  revised  November  1987,  Information 
Processing  Systems  -  Open  Systems  Interconnection  -  Application  Layer  Structure. 


2.4      Application  Layer  -  ASE/ACSE 

[14]     ISO  8649:  1987  (E)  (ISO/IEC  JTC1/SC21  N2326).  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Sen/ice  Definition  for  the  Association  Control  Sen/ice  Element. 

[15]     ISO  8650:  1987  (E)  (ISO/IEC  JTC1/SC21  N2327),  Information  Processing  Systems  -  Open 

Systems  Interconnection  -  Protocol  Specification  for  the  Association  Control  Sen/ice  Element. 

[16]     ISO  8649/DAD2,  Information  Processing  System  -  Open  Systems  Interconnection  -  ACSE 
Sen/ice  Definition:  Draft  Addendum  2  Covering  Connectionless-Mode  ACSE  Sen/ice. 

[17]     ISO  d649/DADl  (ISO/IEC  JTC1/SC21  N3771),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Service  Definition  for  the  Association  Control  Semce  Element  -  Addendum  1 : 
Peer-Entity  Authentication  During  Association  Establisliment 

[18]     ISO  8650/DAD1  (ISO/IEC  JTC1/SC21  N3772),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Protocol  Specification  for  the  Association  Control  Sen/ice  Element  - 
Addendum  1 :  Peer-Entity  Authentication  During  Association  Establishment 
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[19]  ISO  8649/Cor.1 : 1991  (E)  OSO/IEC  JTC1/SC21  N5630).  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Technical  Corrigendum  1  to  ACSE  Service  OSO  8649: 1968)  Covering 
Defects  8649/001.  8649/002  and  8649/003. 

[20]     ISO  8650/Cor.1 : 1991  (E)  OSO/IEC  JTC1/SC21  NS631).  information  Processing  Systems  -  Open 
Systems  Interconnection  -  Technical  Corrigendum  1  to  ACSE  Protocol  (ISO  8650: 1968) 
Covering  Defects  8650/001. 8649/004. 

[20]     ISO  IS  10035: 19e&02-25  OSO/IEC  JTC1/SC21  N  3456).  Infonnation  Processing  Systems  - 

Open  Systems  Interconnection  -  Cormecdonless  ACSE  Protocol  to  Provide  the  Connectlonless- 
H^ode  ACSE  Senrice. 

3  Status 

This  text  is  stat)le. 

NOTE  •  Changes  due  to  errata  are  sunmtarized  in  clause  4 

4  Errata 

4.1  ISO  Defect  Solutions 

This  clause  lists  the  defect  solutions  from  ISO  which  are  currently  recognized  to  be  valid  for  the 
purposes  of  conformance. 

ISO  8326  defect  solutions: 

023. 024 
ISO  8327  defect  solutions: 

037.  038 

4.2  Session  Defect  Solutions  Correcting  CCITT  X.215  and  X.225 

The  following  approved  defect  solutions  have  been  integrated  into  the  current  revisions  of  ISO  8326  and 
ISO  8327.  but  are  not  part  of  CCITT  X215  and  X225  (1984).  The  defect  solutions  must  be  incorporated 
into  CCITT  Session  to  insure  confermance  with  ISO  Session. 

ISO  8326  defect  solutions: 

004.  006.  007.  009.  Oil.  012,  013.  014.  015.  016.  017.  020. 

ISO  8327  defect  solutions: 
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001,  003.  004.  005.  006.  007.  008.  009.  010.  012.  017,  018,  019.  026,  027.  030,  034,  035. 


4.3     Approved  Errata 

Errata  to  this  part  are  marked  with  change  bars;  deleted  text  Is  marked  with  strikeouts  arxJ  new  text  is 
Indicated  by  shading. 

5    Association  Control  Service  Element 


5.1  Introduction 

This  clause  details  the  Implementation  requirements  for  the  Association  Control  Service  Element  (ACSE) 
of  the  Application  layer  as  defined  in  ISO  8649  and  ISO  8650. 


5.3      Protocol  Agreements 

5.3.1  Application  Context 

Values  for  and  uses  of  Application  Context  names  are  detennined  by  specific  ASEs.  Values  used  by 
ASE  SIGS  are  listed  in  the  clause  entitled  'Specific  ASE  Requirements." 

5.3.2  AE  Title 

AE-titles  shall  be  implemented  as  specified  in  ISO  8650/  Con'.l. 

5.3.3  Peer  Entity  Authentication 

if  supported,  peer-entity  authentication  during  association  establishment  shall  be  implemented  as 
specified  in  Addendum  1  to  ISO  8650  (ISO  8650/DADl). 


♦ 


5.2 


Services 


All  ACSE  services  are  within  the  possible  scope  of  a  workshop-conformant  system. 
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5.4  ASN.1  Encoding  Rules 

When  the  ABRT  APDU  is  used  during  the  connection  estabiishment  phase,  Presentation  iayer  negotiation 
is  considered  to  be  complete,  and  the  'direct-reference'  component  of  EXTERNAL  shail  not  be  present. 

5.5  Connectionless 

The  connectionless  ACSE  protocol  shall  be  implemented  as  specified  in  ISO  IS  10035. 

No  further  agreements  t>eyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 
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6  ROSE 

ROSE  shall  be  Implemented  as  specified  In  ISO  DIS  9072-1.2  and  ISO  DIS  9072-2.2. 

No  further  agreements  beyond  those  specified  elsewhere  In  this  part  have  been  made  regarding  this 

standard. 

7  RISE 

RTSE  shall  be  implemented  as  specified  In  ISO  9066-1  and  ISO  9066-2. 

No  further  agreements  beyond  those  specified  elsewhere  In  this  part  have  been  made  regarding  this 
standard. 


8  Presentation 


8.1  Introduction 

This  clause  details  the  implementation  requirements  for  the  Presentation  layer  as  defined  In  the 
Presentation  Service  Definition,  ISO  8822,  and  the  Presentation  Protocol  Definition,  ISO  8823. 

The  task  of  the  Presentation  layer  is  to  carry  out  the  negotiation  of  transfer  syntaxes  and  to  provide  for 
the  transformation  to  and  from  transfer  syntaxes.  The  transformation  to  and  from  a  particular  transfer 
syntax  is  a  local  implementation  issue  arid  Is  not  discussed  within  this  clause.  This  clause  is  concerned 
with  the  protocol  agreements,  and  thus  is  entirely  devoted  to  the  Issues  involved  with  the  negotiation  of 
transfer  syntaxes  and  the  responsibilities  of  the  Presentation  protocol. 


8.2  Service 

Only  the  Kernel  functional  unit  need  be  supported.  The  Context  Management  and  Context  Restoration 
functional  units  are  outside  the  scope  of  these  agreements. 

The  requirement  that  the  Presentation  l<emel  functional  unit  be  Implemented  does  not  imply  that  any  of 
the  Session  functional  units  for  expedited  data,  typed  data,  and  capability  data  and  the  con-esponding 
Presentation  service  primitives  are  required  to  be  Implemented. 
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8.3.1       Transfer  Syntaxes 

The  following  transfer  syntax  must  be  supported  for  all  mandatory  abstract  syntaxes:  the  basic  encoding 
rules  for  ASN.1.  This  syntax  is  derived  by  applying  the  basic  encoding  rules  for  ASN.1  to  the  abstract 
syntax  (see  the  Basic  Encoding  Rules  for  ASN.1,  ISO  8825). 

The  number  of  transfer  syntaxes  proposed  is  dependent  upon  the  recognized  transfer  syntaxes  which 
are  available  to  support  the  particular  abstract  syntaxes  used  by  an  Application  Entity. 


8.3.2       Presentation  Context  Identifier 

A  conformant  implementation  shall  encode  Presentation  context  identifiers  in  the  range  0  to  32,767. 
Implementations  must  be  able  to  handle  a  minimum  of  two  Presentation  contexts  per  connection. 


8.3.3       Default  Context 

if  the  Presentation  expedited  data  service  is  required,  the  default  context  must  be  explicitly  present  in  the 
P-CONNECT  PPDU  at  Presentation  connect  time. 


8.3.4  P-Seiectors 

Local  P-selectors  shall  be  a  maximum  of  four  octets.  This  applies  only  to  P-selectors  in  PPDUs  whose 
receipt  by  a  workshop-confomnant  system  normally  results  in  either  a  P-CONNECT  indication  or  a  P- 
CONNECT  confirmation  being  issued. 


8.3.5       Provider  Abort  Parameters 

No  conformance  requirements  are  implied  by  the  use  of  either  the  Abort-reason  or  the  Event-identifier 
component  of  the  ARP-PPDU.  The  decision  to  include  these  parameters  is  left  up  to  the  implementation 
issuing  the  abort. 


8.3.6      Provider  Aborts  and  Session  Version 

The  Presentation  Provider  Abort  PPDU  (ARP-PPDU)  shall  be  present  regardless  of  the  Session  version  in 
effect  for  a  given  association.  This  precludes  the  use  of  indefinite  length  encoding  of  an  ARP-PPDU 
when  Session  Version  1  is  in  effect. 
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8.3.7  CPC-Type 

Implementations  shall  not  use  any  CPC-type  values  In  the  SS-user  data  parameter  of  the  S-CONNECT 
unless  more  than  one  transfer  syntax  is  proposed  for  a  single  Presentation  context  of  the  Presentation 
data  values.  Each  CPC-type  represents  a  unique  transfer  syntax,  so  if  more  than  one  transfer  syntax  is 
proposed,  CPC-type  values  may  appear  in  that  SS-user-data  parameter. 

For  a  Presentation  context  for  which  the  Basic  Encoding  Rules  are  a  proposed  transfer  syntax,  all  POVs 
In  the  user  data  parameter  of  the  CP  PPDU  must  be  encoded  first  using  the  Basic  Encoding  Rules  and 
must  t>e  examined  by  the  receiving  Presentation  protocol  machine.  Following  CPC-type  values  may  be 
examined  or  ignored  at  the  receiver's  option  (see  ISO  8823,  clause  6.2.5.3). 


8.3.8  Presentation-context-definition-result-list 

No  semantics  are  Implied  by  the  absence  of  the  optional  Presentation-context-definition-result-llst 
component  of  the  CPR-PPDU.  This  component  Is  required  if  the  Provider-reason  is  absent  in  the  CPR- 
PPOU.  If  the  Provider-reason  is  present,  then  the  Presentation-context-definition-result-list  is  optional. 


8.3.9  RS-PPDU 

The  Presentation-context-identifier-list  shall  not  be  present  when  only  the  kernel  functional  unit  Is  in 
effect. 


8.4      Presentation  ASN.1  Encoding  Rules 

If  a  received  PPDU  contains  any  improperly  encoded  data  values  (Including  data  values  embedded 
within  the  User  Data  field  of  a  PPDU)  and  an  abort  is  issued,  then  either  an  ARU  or  an  ARP  shall  be 
issued. 


8.5  General 

A  Presentation  data  value  (PDV)  Is  a  value  of  a  type  in  an  abstract  syntax,  e.g.,  a  value  of  an  ASN.1 
type. 

A  PDV  may  contain  embedded  PDVs  in  different  contexts.  A  change  of  context  within  a  PDV  is  indicated 
by  an  EXTERNAL  EXTERNAL  implies  an  embedded  PDV. 

A  PDV  cannot  t>e  split  across  PDV-llsts  in  fully-encoded  user  data. 

Fully-encoded-data  that  is  a  series  of  PDVs  in  the  same  Presentation  context  (e.g..  grouped  FTAM 
PDUs)  shall  be  encoded  either  as  a  single  PDV-list  (using  the  octet-aligned  choice)  or  as  a  series  of 
PDV-llsts.  each  encoding  either  a  single  PDV  (using  the  single-ASN1-type  choice)  or  multiple  PDVs 
(using  the  octet-aligned  choice).  Note  that  receivers  must  accept  any  of  the  above  encodings. 


8 


Part  5  •  Upper  Layers 

8.6     Connection  Oriented 


December  1992  (Stable) 


The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  be  present  in  a  CP  PPOU  If  and  oNy  If 
more  than  one  transfer  syntax  name  was  proposed  for  the  Presentation  context  of  the  Presentation  data 
values.  The  Transfer-syntax-name  component  of  a  PDV-llst  value  shall  always  be  present  in  a  CPC-type. 
If  only  the  Kernel  functional  unit  is  negotiated,  then  the  Transfer-syntax-name  component  of  a  PDV-list 
value  shall  only  appear  in  the  CP  PPDU  and  CPC-type. 


8.7  Connectionless 

The  connectionless  Presentation  protocol  shall  be  implemented  as  specified  in  ISO  9576. 

The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  be  present  In  a  UD  PPDU  if  and  only  If 
more  than  one  transfer  syntax  name  was  proposed  for  the  Presentation  context  of  the  Presentation  data 
values.  The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  always  be  present  in  a  UDC-type. 
The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  only  appear  in  the  UD  PPDU  and 
UDC-type. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


9  Session 


9.1  introduction 

This  clause  details  the  implementation  requirements  for  the  Session  layer  as  defined  in  the  Session 
Service  Definition.  ISO  8326  and  the  Session  Protocol  Definition.  ISO  8327. 


9.2  Services 

The  following  functional  units  are  within  the  scope  of  a  workshop-conformant  system: 


a) 

Kernel: 

b) 

Duplex; 

c) 

Expedited  Data; 

d) 

Resynchronize; 

e) 

Exceptions; 

f)  Activity  Management; 
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g)  Half-duplex; 

h)  Minor  Synchronize; 

i)  Major  Synchronize; 
j)  Typed  Data. 

9.3      Protocol  Agreements 

9.3.1  Concatenation 

When  a  category  0  SPDU  is  concatenated  with  a  category  2  SPDU.  the  category  0  SPDU  shaR  not 
contain  User  Data. 

Extended  concatenation  is  not  required  and  can  be  refused  using  the  normal  negotiation  mechanisms  of 
the  Session  protocol. 

9.3.2  Segmenting 

Session  segmenting  is  not  required  and  can  be  refused  using  the  normal  negotiation  mechanisms  of  tfie 
Session  protocol.  Ail  conformant  implementations  shall  be  aisle  to  Interwortc  without  Session  segmenting. 

9.3.3  Reuse  of  Transport  Connection 

Reuse  of  a  Transport  connection  is  not  required  and  can  be  refused. 

9.3.4  Use  Of  Transport  Expedited  Data 

The  Session  use  of  Transport  expedited  service  is  optional. 

NOTE  -  A  referencing  ASE  may  require  that  this  feature  shall  t>e  offered  by  an  initiating  implementation  if 
it  is  available,  and  that  it  shall  be  accepted  by  a  responding  implementation  if  it  is  available  and  was 
offered. 

9.3.5  Use  of  Session  Version  Number 

Session  Versions  1  and  2  are  recognized.  Each  relevant  SIG  chooses  the  version  or  versions  of  Session 
which  it  requires  for  a  particular  implementation  phase,  and  these  choices  are  documented  in  clause  12. 

Session  Version  2  specifies  the  use  of  unlimited  user  data  during  connection  establishment  as  dictated 
by  the  AD  2  to  ISO  8327  to  Incorporate  Unlimited  User  Data. 
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All  Session  Version  1  implementations  must  be  able  to  negotiate  Version  1  operation  wlien  responding 
to  a  CONNECT  (CN)  SPDU  proposing  both  Version  1  and  Version  2. 

In  addition,  ail  Session  Version  1  Implementations,  upon  receipt  of  a  CONNECT  (CN)  SPDU  proposing 
only  Version  2,  should  respond  with  a  REFUSE  (RF)  SPDU  containing  a  Reason  Code  indicating  that  the 
proposed  version  Is  not  supported.  Until  pending  defect  reports  are  adopted,  implementations  may 
disconnect. 

If  Session  Versions  1  and  2  are  both  proposed  In  the  CONNECT  (CN)  SPDU,  then  the  maximum  length 
of  the  User  Data  parameter  value  in  the  CONNECT  (CN)  SPDU  shall  be  512  octets  and  a  PGI  field  of 
193  shall  be  associated  with  this  parameter.  This  Implies  that  an  implementation  supporting  both  Session 
Versions  1  and  2  can  establish  a  connection  with  an  implementation  supporting  only  Version  1 . 

If  only  Session  Version  2  is  proposed  in  the  CONNECT  (CN)  SPDU,  then  the  maximum  length  of  the 
Session  User  Data  parameter  value  of  the  S-CONNECT  service  request  shall  be  10,240  octets.  This 
restriction  implies  that  the  OVERFLOW  ACCEPT  (OA)  SPDU  and  CONNECT  DATA  OVERFLOW  (CDO) 
SPDU  are  not  used,  if  the  length  of  the  User  Data  parameter  value  is  no  greater  than  512  octets,  then  an 
associated  PGI  field  of  193  shall  be  used,  otherwise  a  PGI  field  of  194  shall  be  used. 

When  Session  Version  2  is  negotiated,  then  in  all  SPDUs  the  maximum  length  of  the  User  Data 
parameter  value  with  an  associated  PGI  field  of  193  shall  be  10,240  octets.  Workshop-conformant 
Session  Version  2  Implementations  need  only  support  the  maximum  data  lengths  specified  in  the 
Specific  ASE  Requirements  section. 


9.3.6       Receipt  of  Invalid  SPDUs 

Upon  receipt  of  an  invalid  SPDU,  the  SPM  shall  take  any  action  in  A.4.3  of  the  Session  Protocol 
Definition  ISO/IS  8327  except  Action  d. 


9.3.7       Invalid  SPM  Intersections 

If  the  conditions  described  in  A.4.1.2  of  the  Session  Protocol  Definition  ISO/IS  8327  are  satisfied,  the 
SPM  shall  always  take  the  actions  described  by  A.4.1.2  a. 

This  implies  that  no  S-P-EXCEPTION-REPORT  indications  will  be  generated  nor  EXCEPTION  REPORT 
SPDUs  sent  due  to  invalid  intersections  of  the  Session  state  table  resulting  from  received  SPDUs. 


9.3.8  S-Selectors 

S-selectors  shall  be  a  maximum  of  16  octets. 
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The  connectionless  Session  protocol  shall  be  Implemented  as  specified  in  ISO  9548. 

No  further  agreements  t>eyond  those  specified  elsewhere  In  this  part  have  been  nrtade  regarding  this 
standard. 


10  UNIVERSAL  ASN.1  ENCODING  RULES 


10.1  TAGS 

The  maximum  value  of  an  ASN.1  t)asic  encoding  tag  that  need  be  handled  by  a  workshop-confonnant 
implementation  shall  be  16,383.  This  is  the  maximum  unsigned  number  that  can  be  represented  In  14 
bits,  therefore,  the  maximum  encoding  of  a  tag  occupies  3  octets. 


10.2    Definite  Length 

The  maximum  value  of  an  ASN.1  length  octets  component  that  need  be  handled  by  an  workshop- 
conformant  implementation  shall  be  4,294,967,295.  This  is  the  maximum  unsigned  integer  that  can  be 
represented  in  32  bits,  therefore,  the  maximum  encoding  of  a  length  octets  component  will  occupy  5 
octets.  Also,  note  this  restriction  does  not  apply  to  indefinite  length  encoding. 


10.3  External 

it  is  assumed  that  "Presentation  layer  negotiation  of  encoding  rules"  is  always  In  effect,  and  therefore 
clause  32.5  of  the  Specification  of  ASN.1,  ISO  8824  never  applies. 

If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  Is  an  instance  of  a  single  ASN.1  type  encoded 
according  to  the  Basic  Encoding  Rules  for  ASN.1.  then  the  option  "single-ASN.I-type"  shall  be  chosen  as 
its  encoding. 

if  a  data  value  to  be  encapsulated  In  an  EXTERNAL  type  Is  encoded  as  an  integral  number  of  octets, 
and  the  above  does  not  apply,  then  the  option  "octet-aligned"  shall  be  chosen  as  Its  encoding. 


10.4  Integer 

Any  inckJence  of  an  ASN.1  INTEGER  type  defined  in  an  abstract  syntax  describing  protocol  control 
information  must  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  four  octets,  unless 
an  explicit  Workshop  agreement  to  the  contrary  Is  made  for  a  specific  INTEGER  type. 
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10.5    String  Types 

The  contents  octets  for  a  constructed  encoding  of  a  BIT  STRING,  OCTET  STRING,  or  character  string 
value  consists  of  the  complete  encoding  of  zero,  one,  or  more  data  values,  and  the  encoding  of  these 
data  values  must  t>e  primitive. 


10.6    Bit  String 


A  responding  Implementation  must  be  able  to  accept  all  valid  encodings  of  the  BIT  STRING  type. 
NOTES: 

1.  Local  restraints  may  restrict  the  length  of  BIT  STRING  which  can  be  decoded.  However,  the  minimum 
length  supported  shall  be  at  least  equal  to  the  currenly  defined  nurnber  of  bits  of  the  referencing 
specification. 

2.  For  Implementation  efficiency.  It  Is  recommended  that  Initiating  applications  should  encode  as  many 
bits  as  are  defined  at  the  time  the  implementation  is  released,  but  no  more. 


1 1  Cliaracter  Sets 

See  Part  21  of  Working  Implementation  Agreements. 


12  Conformance 

In  order  for  an  Implementation  to  be  In  conformance  with  the  Implementors'  agreements,  the  rules  below 
shall  be  followed: 

a)  A  conformant  implementation  must  meet  all  of  the  requirements  of  this  specification.  All 
documents  referenced  in  the  Upper  Layers  part  shall  be  used  as  the  supporting  documents  for 
all  implementations  of  ACSE,  ROSE,  RTSE,  Presentation,  or  Session.  The  full  references  for 
these  documents  are  in  clause  2. 

b)  Workshop-conformant  implementations  shall  be  ISO  conformant.  PICS  may  contain 
limitations  on  length  or  value  aspects  of  a  protocol.  PICS  of  workshop-conformant  systems  shall 
not  contain  restrictions  more  severe  than  those  in  these  Implementation  agreements. 

NOTE  -  An  implementation  may  atx>rt  a  connection  if  the  constraints  specified  in  these  agreements  are 
violated. 
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13  Specific  ASE  Requirements 

The  following  list  for  each  ASE  the  corresponding  SIG's  requirements  of  and  restrictions  on  ACSE. 
ROSE,  RISE,  Presentation,  and  Session. 

All  listed  requirements  and  restrictions  shall  t>e  included  in  an  NIST-conformant  system  and  shall  be 
implemented  in  accordance  with  these  Implementor's  agreements. 

13.1  FTAMPhase2 

13.1.1  ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  FTAM"  {  iso(1)  standard(0)  8571  application-context  iso-ftam(l)  }  -  implies 
the  use  of  the  ACSE  and  the  RAM  ASE. 

A  value  is  defined  for  the  AE  Title  only  to  satisfy  the  FTAM  requirement  for  exchanging  fields  of  this 
type.  This  value  does  not  identify  an  Application  Entity  and  carries  no  semantics. 

If  the  AE  title  is  used,  AE-title-form2  shall  be  supported.  Support  of  AE-title-form2  includes  support  of  AP- 
title-form2  and  AE-qualifier-form2. 

The  value  for  the  AP  title  is  {  1  3  9999  1  ftam-nil-ap-title  (7)  }  at  this  time.  Values  for  the  AE  qualifier  are 
outside  the  scope  of  these  agreements. 

The  use  of  AP  invocation  identifiers  and  AE  invocation  identifiers  by  FTAM  is  outside  the  scope  of  these 
agreements. 

13.1.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  3  Presentation  Contexts  must  be  supported. 
Abstract  Syntaxes: 

a)  Abstract  Syntaxes  for  conformant  Implementations 

1)  "ISO  8650-ACSE1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l) 
apdus(0)  version1(1)  } 

2)  "FTAM-PCI"  {  iso(1)  standard(0)  8571  abstract-syntax(2)  ftam-pci(1)  } 

3)  "FTAM  unstructured  binary  abstract  syntax"  {  iso(1)  standard(0)  8571 
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abstract-syntax(2)  un8tnjctijred-binary(4)  } 
Eflilor'f  Note  -  In  Definitions  below.  *NBS"  designation  will  be  preserved. 

b)  Ak)stract  Syntaxes  Depending  on  Implementation  Profile 

1)  "FTAi^/l-FADU''  {  l8o(1)  8tandard(0)  abstract-syntax(2)  ftam-fadu(2)  } 

2)  "FTAM  unstructured  text  at)stfact  syntax"  {  iso(1)  standard(0)  8571  abstract-8yntax(2) 
unstructured-text(3)  } 

3)  'NBS  abstract  syntax  ASI'  {  too  Identified-organlzation  oiw(14)  ftamsig(5) 
at)stract-syntax(2)  nt>s-as1(1) } 

4)  'NBS  fie  directory  entry  abstract  syntax"  {  iso  identified-organization  oiw(14) 
ftamsig(5)  abstract-syntax(2)  nl)s-a82(2)  > 

c)  Associated  Transfer  Syntax: 

1)  'Basic  Encoding  of  a  single  ASN.1  type'  { jolnt-isoKx:ltt(2)  asnl  (1) 
basic-encoding(1 )} 

Editor's  Note  •  The  dwiges  above  involving  *0IW(14)'  were  not  explicitly  mentioned  at  the  March  1990 
Plenary,  but  were  implied  from  a  correspondingly  approved  FTAM  motion. 

13.1.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 
Version  Uwnlber.  2 

Maximum  size  of  User  Data  parameter  field:  10.240 

1 3.1 .4  Session  Options 

Session  Functional  Untts: 

a)  resynchronize  -  only  a  Resynchronize  Type  value  of  "abandon" 

b)  minor  synchronize 
NOTES 
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1  The  minor  synchronize  functional  unit  is  required  whenever  the  resynchronize  functional  unit  is  available.  I 

2  The  default  value  for  Minor  Sync  Point  Sync  type  Item  PV-fleld  shall  be  absent  If  explicit  confirmation  Is  ' 
required  (per  ISO  8327.  8.3.20.3)  (SIA->  value  of  $). 

I 

■  ■  i 

13.1.5     ASN.1  Encoding  Requirements  u 

Some  INTEGER  types  of  the  FTAM  PCI  may  exceed  the  maximum  size  specified  in  the  UNIVERSAL 
ASN.1  ENCODING  Rules.  See  the  Range  of  values  for  INTEGER  type  Parameters  of  the  FTAM  part 

13.2  MHS 

13.2.1     Phase  1  (1984  X.400)  Session  Requirements  I 

Session  Functional  Units: 


a) 

kemei 

b) 

half -duplex 

c) 

exceptions 

d) 

activity  nrranagement 

e) 

minor  synchronize 

Version  Number:  1 

Maximum  size  of  User  Data  parameter  field:  512  ' 
NOTES 

1  Restricted  use  is  made  by  the  RTS  of  the  Session  services  implied  by  the  functional  units  selected. 
Specifically,  1)  No  use  is  made  of  S-TOKEN-GIVE,  and  2)  S-PLEASE-TOKENS  only  asks  for  the  data  token. 

2  In  the  S-CONNECT  SPDU.  the  Initial  Serial  Number  should  not  be  present. 

3  The  format  of  the  Connection  Identifier  in  the  S-CONNECT  SPDU  is  described  in  Version  S  of  the  X.400-  f 
Series  Implementors'  Guide. 

13.2.2     Phase  2,  Protocol  PI  (1988  X.400)  i 
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13.2.2.2  RTSE  Requirements 

The  RTSE  requirements  are: 

a)  Monologue 

b)  TWA  -  optional 

c)  checkpointing: 

1)  minimum  checkpointsize  =  1 

2)  minimum  windowsize  =  1 

d)  no  checkpointing 
For  the  Monologue  Association: 

a)  initiator  keeps  initial  turn 

b)  APDUs  are  transferred  from  initiator  to  responder  only 

c)  no  tum  passing 

d)  only  the  initiator  effects  the  orderly  release  of  an  association 
For  the  two  way  alternate  Association 

a)  the  initiator  may  keep  or  pass  the  initial  turn,  at  binding 

b)  APDUs  are  transferred  by  the  holder  of  the  tum 

c)  only  the  initiator  effects  the  orderly  release  of  an  association,  when  it  possesses  the  tum 

13.2.2.3  ACSE  Requirements 

As  per  Phase  2,  Protocol  P7. 
Application  Contexts: 

a)  "MTS-transfer-protocoi-1984"  -  mandatory 

b)  "MTS-transfer-protocol"  -  mandatory 
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c)  "MTS-transfer"  -  mandatory 

i 

13.2.2.4  Presentation  Requirements 

Presentation  Functional  Units:  kernel 
Presentation  Contexts:  at  least  3  must  be  supported 
Abstract  Syntaxes: 

a)  "ISO  seso-ACSEI'  {jolnt-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(0) 
versionl(l)  } 

b)  "MTS-RTSE" 

c)  "MTSE" 

d)  Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-lso-ccitt(2) 
asn1(1)  basic-encoding(l)  } 

13.2.2.5  Session  Requirements 

As  per  Phase  2,  Protocol  P7. 

13.2.3     Phase  2,  Protocol  P7  (1988  X.400) 

13.2.3.1  ROSE  Requirements 

Operation  and  association  classes  are  used  as  per  the  standard. 

13.2.3.2  RTSE  Requirements 

The  RTSE  requirements  are: 

a)  TWA 

b)  normal-mode 

c)  checkpointing 

d)  minimum  checkpointsize  =  1 

e)  minimum  windowsize  =  1 
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f)  no  checkpointing 
For  the  Monologue  Association: 

a)  initiator  keeps  initial  turn 

b)  APDUs  are  transferred  from  Initiator  to  responder  only 

c)  no  turn  passing 

d)  only  the  initiator  effects  the  orderly  release  of  an  association 
For  two  way  alternate  Association: 

a)  the  initiator  may  keep  or  pass  the  initial  turn,  at  binding 

b)  APDUs  are  transferred  by  the  holder  of  the  tum 

c)  only  the  Initiator  effects  the  orderly  release  of  an  association,  when  It  possesses  the  tum 

13.2.3.3  ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

The  use  of  AP-TITI^.  AE-QUAUFIER,  AP-INVOCATION-ID.  and  AE-INVOCATiON-iD  is  not 
recommended;  however,  a  receiving  entity  must  be  capable  of  Ignoring  them  (if  present)  without  refusing 
the  connection. 

Application  Contexts: 

a)  "MS-access"  -  mandatory;  normal  mode 

b)  "MS-reliabie-access*  -  optional;  normal  mode 

13.2.3.4  Presentation  Requirements 

Presentation  Functional  Units:  kernel 
Presentation  Contexts:  at  least  5 
Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-lso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(0) 
versionl(l)  } 

b)  I^SBind/MSUnbind  (with  or  without  RTSE) 
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c)  MSSE  (Message  Submission) 

d)  MASE  (Message  Administration) 

e)  MRSE  (Message  Retrieval) 

Associated  Transfer  Syntax:  'Basic  Encoding  of  a  singie  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
k)asic-encoding(l)  } 

13.2.3.5      Session  Requirements 

Session  Functionai  Units: 

a)  l<emei 

b)  half-dupiex  (if  RTSE  is  supported) 

c)  fuil-dupiex  (if  RTSE  is  not  supported)  4 

d)  exceptions 

e)  activity  management 

f)  minor  synchronize 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  fieid:  10.240 
NOTES 

1  MHS  proposes  t)oth  versions  1  and  2  for  pass  through  mode  (X.410  mode),  but  only  version  2  for 
normal  mode. 

2  Restricted  use  is  made  by  the  RTS  of  the  Session  services  implied  by  the  functional  units  selected. 
Specifically,  no  use  is  made  of  S-TOKEN-GIVE,  and  S-PLEASE-TOKENS  only  asks  for  the  data  token. 

3  In  the  S-CONNECT  SPDU,  the  Initial  Serial  Number  should  not  be  present. 

4  The  format  of  the  Connection  identifier  in  the  S^ONNECT  SPDU  is  described  in  Version  5  of  the  X.400- 
Series  Implementors'  Guide. 

13.2.4      Phase  2,  Protocol  P3  (1988  X.400) 
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13.2.4.1  ROSE  Requirements 

As  per  Phase  2,  P7. 

13.2.4.2  RTSE  Requirements 

As  per  Phase  2,  P7. 

13.2.4.3  ACSE  Requirements 

As  per  Phase  2,  P7. 
Application  Contexts: 

a)  "MTS-access"  -  mandatory 

b)  "MTS-reiiable-access"  -  optional 

c)  "MTS-forced-access"  -  mandatory 

d)  "MTS-forced-reliable-access"  •  optional 

13.2.4.4  Presentation  Requirements 

As  per  Phase  2,  P7. 

13.2.4.5  Session  Requirements 

As  per  Phase  2,  P7. 

13.3    DS  Phase  1 

13.3.1      ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 
Application  Contexts: 

a)  "id-ac-directoryAccessAC"  {  joint-iso-ccitt(2)  ds(5)  3  1  } 

b)  "id-ac-directorySystemAC  {  joint-isoK;citt(2)  ds(5)  3  2} 
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13.3.2  Presentation  Requirementa 

Presentation  Functional  Units:  Itemel 

Presentation  Contexts:  At  least  2  Presentation  Contexts  must  be  supported. 
Abstract  Syntaxes: 

a)  ISO  8650-ACSEr  { Joim-i80<«itt(2)  as80ciation-contrd(2)  abstract-^yntaxO)  ^ 
versionl(l)  } 

b)  "id-as-directoryAccessAS"  joint-iso-ccilt(2)  d8(5)  9  1  > 

c)  "id-as-directorySystemAS"  { Joint-isoHx:ilt(2)  d8(5)  9  2  } 

Associated  Transfer  Syntax:  'Basic  Encoding  of  a  single  ASN.1  type'  { Joint-i80-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.3.3  Session  Requirements 

Session  Functional  Units: 

a)  Icemel 

b)  duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10.240 

13.4    Virtual  Terminal 
13.4.1      Pliase  la 

13.4.1.1      ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  'ISO  VT  {  iso(l)  standard(0)  9041  appllcation-context(l)  }•  implies  the  use  of  the 
ACSE  and  the  VT  ASE 
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13.4.1.2  Presentation  Requirements 

Presentation  Functional  Units:  l<ernel 

Presentation  Contexts:  at  least  2  must  t>e  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSEr  {  jolnt-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(0) 
version!  (1)  } 

b)  "VT  Basic"  {  iso(1)  standard(0)  9041  abstract-syntax(2)  } 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type'  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.4.1.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 

c)  expedited  data 

d)  major  synchronize 

e)  resynchronize  -  only  a  Resynchronize  Type  value  of  "restart" 

f)  typed  data 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 
Session  Options:  expedited  data 

13.4.2     Phase  lb  and  Phase  II 

13.4.2.1       ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  VT"  {  iso(1)  standard(0)  9041  application-context(l)  }  -  implies  the  use  of  the 
ACSE  and  the  VT  ASE 
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13.4.2.2  Presentation  Requirements 

Presentation  Functional  Units:  l<emel 

Presentation  Contexts:  at  least  2  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  seso-ACSEl"  { joint-iso-ccitt(2)  as8ociation-control(2)  abstract-syntax(l)  apdus(0) 
version1(1)  } 

b)  "VT  Basic"  {  iso(1)  standard  (0)  9041  abstract-syntax(2)  } 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type'  {  Joint-iso-ccitt(2)  asn1(1) 
t)asic-encoding(l)  } 

13.4.2.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 

c)  half-duplex 

d)  expedited  data 

e)  major  synciironize 

f)  resynchronize  -  only  a  Resynchronize  Type  value  of  "restart" 

g)  typed  data 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10.240 
Session  Options:  expedited  data 
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13.5.1  ACSE  Requirements 

ACSE  Functional  Units:  Kernel 

Application  Context:  'ISO  MMS'  {  iso(1)  standard(0)  9506  part(2)  mms-application-context-verslon1(3)}  - 
implies  use  of  ACSE  and  MMS  ASE 

13.5.2  Presentation  Requirements 

Presentation  Functional  Units:  Kernel 

At  least  2  Presentation  Contexts  must  t>e  supported. 

Abstract  Syntaxes: 

a)  "mms-abstract-syntax-major-verslonl"  {  lso(1)  standard(0)  9506  part(2)  mms-abstract-syntax- 
major-versionl  (1)} 

b)  'ISO  8650-ACSEr  {joint-lso-ccltt(2)  association-control(2)  abstract-syntax(l)  apdus(0) 
versionl(l)} 

Associated  Transfer  Syntax:  'Basic  Encoding  of  a  single  ASN.1  type"  {joint-iso-ccitt(2)  asn1(1)  tMSic- 
encoding(l)} 

13.5.3  Session  Requirements 

Session  Functional  Units: 

a)  Kernel 

b)  Duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10.240 
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13.6  Transaction  Processing 

See  Working  Implementation  Agreements  Document. 

13.7  Network  Management 


December  1992  (Stable) 


13.7.1  ROSE  Requirements 

The  Rose  requirements  are  as  specified  in  ISO  9596  section  5.2:  Underlying  Services,  and  section  6.2 
Remote  Operations. 

Operations  Classes:  1 ,  2,  and  5 

Association  Classes:  3 

13.7.2  ACSE  Requirements 

ACSE  Functional  Units:  kernel 
Application  Contexts:  as  defined  by  [SMO] 

AE-Title:  The  association  responder  shall  support  both  forms  of  the  AE-Title.  The  association  requestor 
may  use  either  form  of  the  AE-Title. 

13.7.3  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  2  must  be  supported. 

Abstract  Syntaxes: 

a)  "ISO  Seso-ACSEI"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(0) 
version1(1)  } 

b)  "CMIP-PCI"  {joint-iso-ccitt(2)  ms(9)  cmip(1)  cmip-pci(1)  abstractSyntax(4)} 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 
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13.7.4     Session  Requirements 

Session  Functional  Units: 

a)  l(emel 

b)  duplex 
Version  Numt)er:  2 

Maximum  size  of  User  Data  parameter  field:  10,240. 

13.8    Remote  Database  Access 

13.8.1  ACSE  Requirements 

ACSE  Functional  Units:  Kernel 
Application  Contexts: 

a)  "RDA-SOL-BASiC-APPL-CONTEXT-Vr  {l8o(1)  standard(0)  rda(9579)  part-2(2)  basic-ac(2) 
version-l(l)}  implies  use  of  the  ACSE  and  RDA  SQL  ASEs; 

b)  "RDA-SQL-TP-APPL-CONTEXT-Vr  {lso(1)  standard(0)  rda(9579)  pait-2(2)  tp-ac(3)  version- 
1(1)}  implies  use  of  the  ACSE,  RDA  SQL,  TP.  and  optionally  CCR  ASEs. 

13.8.2  Presentation  Requirements 

Presentation  Functional  Units:  Kernel 

13.8.2.1      Presentation  Contexts  for  the  RDA  Basic  Application  Context 

At  least  2  presentation  contexts  must  be  supported; 
Abstract  Syntaxes: 

a)  ISO  seSG-ACSEr  {joint-lso-ccitt(2)  assoclatlon-control(2)  abstract-syntax(l)  apdus(0) 
versionl(l)}; 

b)  "RDA-SQL-ABSTRACT-SYNTAX-Vr  {iso(1)  standard(0)  rda(9579)  part-2(2)  abstract-syntax(l) 
version-l(l)}; 

Associated  Transfer  Syntax:  'Basic  Encoding  of  a  single  ASN.1  type'  {loint-iso^ltt(2)  a8n1(1) 
basic-encoding(1 ) } ; 

27 


Part  5  -  Upper  Layers 

13.8.3     Session  Requirements 

Session  Functional  Units: 

a)  Kernel; 

b)  Duplex; 

Version:  2: 

Maximum  size  of  User  Data  parameter  field:  10,240. 


December  1992  (Stable) 
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Annex  A  (normative) 
Object  Identifier  Register 

Editor's  Note  -  Annexes  A  and  B  have  been  switched  to  place  the  informative  annex  after  the  normative 
annex. 


A.1      Register  Index 

Each  entry  in  the  Index  contains  an  object  Identifier  value  and  a  reference  to  the  clause  describing  the 
object  identifier's  use: 

a)  {  lso(1)  ldentified-organlzatlon(3)  oiw(14)  ulslg(8)  appllcation-context(l)  nil(1)  }  Is  defined  In 
14.2; 

b)  {  lso(1)  ldentlfied-organlzatlon(3)  olw(l4)  ulslg(8)  abstract-syntax(2)  octet-stilng(l)  }  Is 
defined  in  14.2. 


A.2     Object  Identifier  Descriptions 

{  lso(1)  ldentified-organization(3)  olw(14)  ulslg(8)  appllcatlon-context(l)  nll(1)  } 

This  application  context  may  be  used  by  applications  having  a  prior  agreement  regarding  the  application 
context. 

NOTE  -  This  value  is  intended  to  be  used  by  private  applications  that  have  an  a  priori  agreement 
concerning  the  set  of  ASEs,  related  options,  and  any  other  information  necessary  for  the  interworking  of 
AEs  on  an  application  association.  This  value  does  not  identify  any  specific  application  context  and  cannot 
be  used  to  Identify  the  intended  communications  environment  for  the  application  association.  Therefore,  it 
Is  strongly  recommended  that  private  applications  define  and  register  an  object  identifier  for  their 
application  context. 

{  lso(1)  identified-organization(3)  olw(14)  ulslg(8)  abstract-syntax(2)  octet-strlng(l)  } 


NIST-OIW-ULSIG-AS -octet-string 
DEFINITIONS  : : =  BEGIN 

Single-octet-string  ::=  OCTET  STRING 
END 


This  abstract  syntax  may  be  used  by  applications  having  a  prior  agreement  regarding  the  content  of  the 
octet  string. 
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Annex  B  (informative)  

Recommended  Practices 

Edttor'S  Note  -  Annexes  A  and  B  have  been  switched  to  place  the  infbmnative  annex  after  the  normative 
annex. 

The  optional  "Reflect  Parameter  Values"  parameter  In  the  Provider  ABORT  SPDU  shall  be  encoded  so  as 
to  represent  the  Session  connection  state,  the  incoming  event  and  the  first  invalid  SPDU  field  exactly  at 
the  nrKKnent  a  protocol  error  was  detected. 

The  first  octet  encodes  the  Session  state  as  a  numt)er  relative  to  0  as  detailed  in  tat)le  1. 
The  second  octet  encodes  the  incoming  event  as  a  number  relative  to  0  as  detailed  in  tat)le  2. 
The  third  octet  contains  the  SI,  PGI,  or  PI  Code  of  any  SI  field.  PGI  unit  or  PI  unit  in  enror. 
NOTE  •  The  remaining  6  octets  are  undefined  herein. 
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Table  1  -  Session  States 


state 

Rel 

Description 

1 

0 

Idle,  no  transport  connection 

IB 

1 

Wait  for  T-connect  confirm 

IC 

2 

Idle,  transport  connected 

2A 

3 

Wait  for  the  ACCEPT  SPDU 

3 

4 

Wait  for  the  DISCONNECT  SPDU 

8 

5 

Wait  for  the  S-CONNECT  response 

9 

6 

Wait  for  the  S-RELEASE  response 

16 

7 

Wait  for  the  T-DISCONNECT  indication 

713 

8 

Data  Transfer  state 

lA 

9 

Wait  for  the  ABORT  ACCEPT  SPDU 

4A 

10 

Wait  for  the  MAJOR  SYNC  ACK  SPDU  or  PREPARE  SPDU 

4B 

11 

Wait  for  the  ACTIVITY  END  ACK  SPDU  or  PREPARE  SPDU 

5A 

12 

Wait  for  the  RESYNCHRONIZE  ACK  SPDU  or  PREPARE  SPDU 

5B 

13 

Wait  for  the  ACTIVITY  INTERRUPT  SPDU  or  PREPARE  SPDU 

5C 

14 

Wait  for  the  ACTIVITY  DISCARD  ACK  SPDU  or  PREPARE  SPDU 

6 

15 

Wait  for  the  RESYNCHRONIZE  SPDU  or  PREPARE  SPDU 

lOA 

16 

Wait  for  the  S-SYNC-MAJOR  response 

lOB 

17 

Wait  for  the  S-ACTIVITY-END  response 

llA 

18 

Wait  for  the  S-RESYNCHRONIZE  response 

IIB 

19 

Wait  for  the  S-ACTIVITY-INTERRUPT  response 

lie 

20 

Wait  for  the  S-ACTIVITY-DISCARD  response 

15A 

21 

After  PREPARE,  wait  for  the  MAJOR  SYNC  ACK  SPDU 

or  the  ACTIVITY  END  ACK 

15B 

22 

After  PREPARE,  wait  for  the  RESYNCHRONIZE  SPDU 

or  the  ACTIVITY  DISCARD  SPDU 

15C 

23 

After  PREPARE,  wait  for  the  RESYNCHRONIZE  ACK  SPDU, 

or  the  ACTIVITY  INTERRUPT  ACK  SPDU 

or  the  ACTIVITY  DISCARD  ACK  SPDU 

18 

24 

Wait  for  GIVE  TOKENS  ACK  SPDU 

19 

25 

Wait  for  a  recovery  request  or  SPDU 

20 

26 

Wait  for  a  recovery  SPDU  or  request 

21 

27 

Wait  for  the  CAPABILITY  DATA  ACK  SPDU 

22 

28 

Wait  for  the  S-CAPABILITY-DATA  response 

ID 

29 

Wait  for  the  CONNECT  DATA  OVERFLOW  SPDU 

2B 

30 

Wait  for  the  OVERFLOW  ACCEPT  SPDU 

15D 

31 

After  PREPARE,  wait  for  the  ABORT  SPDU 
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Tabid  2  •  Incoming  Events 
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29 

S-CONTROL-GIVE  reauest 

SEXreg 

30 

S-EXPEDI TED-DATA  request 

SGTreq 

31 

S-TOKEN-GIVE  request 

SPTreq 

32 

S-TOKEN-PLEASE  request 

SRELrsp 

33 

S-RELEASE  response  reject 

SRSYNreg(a) 

34 

S-RESYNCHRONIZE  request  abandon 

SRSYNreq(r) 

35 

S-RESYNCHRONIZE  request  restart 

SRSYNreq(s) 

36 

S-RESYNCHRONIZE  request  set 

SRSYNrsp 

37 

S-RESYNCHRONIZE  response 

SSYNMreq 

38 

S-SYNC-MAJOR  request 

SSYNMrsp 

39 

S-SYNC-MAJOR  response 

SSYNmreq 

40 

S-SYNC-MINOR  request 

SSYNmrsp 

41 

S-SYNC-MINOR  response 

STDreq 

42 

S-TYPED-DATA  request 

SUERreq 

43 

S-U-EXCEPTION-REPORT  request 

32 


Part  5  -  Upper  Layers  December  1992  (Stable) 


Table  2  -  Incoming  Events  (continued) 


Event 

Rel 

Description 

AB-r 

44 

ABORT  -  reuse  SPDU 

AD 

45 

ACTIVITY  DISCARD  SPDU 

ADA 

46 

ACTIVITY  DISCARD  ACK  SPDU 

AE 

47 

ACTIVITY  END  SPDU 

AEA 

48 

ACTIVITY  END  ACK  SPDU 

AI 

49 

ACTIVITY  INTERRUPT  SPDU 

AIA 

50 

ACTIVITY  INTERRUPT  ACK  SPDU 

AR 

51 

ACTIVITY  RESUME  SPDU 

AS 

52 

ACTIVITY  START  SPDU 

CD 

53 

CAPABILITY  DATA  SPDU 

CDA 

54 

CAPABILITY  DATA  ACK  SPDU 

ED 

55 

EXCEPTION  DATA  SPDU 

ER 

56 

EXCEPTION  REPORT  SPDU 

EX 

57 

EXPEDITED  DATA  SPDU 

FN-r 

58 

FINISH  -  reuse  SPDU 

6T 

59 

GIVE  TOKENS  SPDU 

6TA 

60 

GIVE  TOKENS  ACK  SPDU 

GTC 

61 

GIVE  TOKENS  CONFIRM  SPDU 

MAA 

62 

MAJOR  SYNC  ACK  SPDU 

MAP 

63 

MAJOR  SYNC  POINT  SPDU 

MIA 

64 

MAJOR  SYNC  ACK  SPDU 

MIP 

65 

MINOR  SYNC  POINT  SPDU 

NF 

66 

NOT  FINISHED  SPDU 

PR-MAA 

67 

PREPARE  (MAJOR  SYNC  ACK)  SPDU 

PR-RA 

68 

PREPARE  (RESYNCHRONIZE  ACK)  SPDU 

PR-RS 

69 

PREPARE  (RESYNCHRONIZE)  SPDU 

PT 

70 

PLEASE  TOKENS  SPDU  with  Token  Item  Paranet  r 

RA 

71 

RESYNCHRONIZE  ACK  SPDU 

RF-r 

72 

REFUSE  -  reuse  SPDU 

RS-a 

73 

RESYNCHRONIZE  -  abandon  SPDU 

RS-r 

74 

RESYNCHRONIZE  -  restart  SPDU 

RS-s 

75 

RESYNCHRONIZE  -  set  SPDU 

TD 

76 

TYPED  DATA  SPDU 

CDO 

77 

CONNECT  DATA  OVERFLOW  SPDU 

0A7 

80 

VERFLOW  ACCEPT  SPDU 

PR-AB 

79 

PREPARE  (ABORT)  SPDU 

I 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Registration  Special  Interest  Group 
(RSIG)  of  the  Open  Systems  Environment  implementors'  Workshop  (OIW). 

This  part  replaces  the  previously  existing  chapter  on  this  subject. 

Future  changes  and  additions  to  this  version  of  these  implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  stril(eout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  6  -  Registration  Authority  Procedures  for  tlie  OSE  Implementors' 
Worlcshop  (OIW) 

NOTE  -  Previous  material  in  this  section  has  been  deleted  and  is  no  longer  applicable. 

This  chapter  establishes  the  policies  and  procedures  for  the  registration  of  technical  objects  defined  by  the 
OSE  Implementors'  Workshop.  Procedures  for  registering  operational  and  administrative  objects,  such  as 
the  MHS  ADMO  and  PRMD  names  and  addresses,  are  outside  the  scope  of  this  chapter. 


0  Introduction 

In  order  to  communicate,  it  is  necessary  to  identify  the  objects  involved  in  communication.  These  objects 
have  names  and  addresses.  A  name  identifies  an  object  within  the  domain  of  a  registration  authority.  An 
address  is  a  name  that  is  used  to  specify  the  physical  or  logical  location  of  an  object. 

OSI  names  and  addresses  consist  of  attributes  which  are  hierarchical  in  nature  and  which  combine  to 
identify  or  locate  an  OSi  object  unambiguously.  Since  the  relationship  between  the  components  of  a  name 
or  address  is  hierarchical,  it  follows  that  the  registration  authority  for  names  and  addresses  should  also  be 
hierarchical.  A  governing  organization  does  not  always  have  sufficient  knowledge  of  organizations  lower 
in  the  hierarchy  to  assign  values  within  those  organizations.  Thus,  an  approach  frequently  taken  is  to 
delegate  registration  authority  to  the  lower  organizations. 

Hierarchy  implies  an  inverted  tree-like  structure  where  the  number  of  objects  increases  from  the  root  of  the 
tree  to  the  leaves  of  the  tree.  At  the  root  of  the  tree,  there  is  one  designator  that  has  the  greatest  scope 
of  authority  (largest  domain).  This  designator  assigns  identifier  values  to  objects  under  its  authority.  Each 
of  these  objects  has  a  smaller  scope  of  authority  than  the  objects  immediately  above  and  may  create  zero, 
one,  or  many  subauthorities  at  the  next-lower  level.  The  number  of  levels  in  such  a  tree-like  structure  is 
arbitrary. 


1  Scope 

This  part  defines  registration  procedures  for  OSE  implementors'  Workshop  (OiW)  information  objects  and 
Identifies  additional  registration  requirements.  These  procedures  shall  be  used  by  the  Special  Interest 
Groups  (SIGs)  of  the  Workshop  to  register  information  objects  used  in  OSI  communications  according  to 
the  OiW  Agreements  Document. 

In  this  part,  the  OIW  and  the  SIGs  themselves  are  assigned  arcs  in  the  object  identifier  tree.  These  arcs  are 
for  OlW-specified  objects.  The  SIGs  should  note  that,  as  national  and  international  registration  authorities 
are  established,  objects  of  interest  beyond  the  Workshop  are  more  appropriately  registered  by  a  higher  level 
in  the  hierarchy.  This  will  allow  more  widespread  acceptance  of  the  registered  objects. 

This  part  is  structured  as  follows:  6.2  describes  the  information  objects  that  need  to  be  registered,  and  6.3 
describes  a  registration  procedures  for  OiW  object  identifiers.  Annex  A  lists  the  object  identifier  component 
values  assigned  to  the  OIW  and  the  SIGs.  Annex  B  discusses  object  identifiers  used  in  the  1987  and  1988 
Stable  Implementation  Agreements.  Annex  C  presents  guidelines  for  registering  changes  to  technical 
objects.  The  appendices  are  integral  parts  of  this  specification. 
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2  Normative  References 

3  Registered  Information  Objects 

if  networks  are  to  interoperate  as  envisioned  in  the  OSI  model,  there  must  be  a  universal  open  arxl  agreed 
upon  naming  schema.  There  are  many  information  objects  that  fall  under  this  requirement 

Some  of  the  following  objects  are  registered  in  the  standards,  some  are  registered  by  OIW  arxJ  others  by 
other  registration  authorities.  An  example  list  of  objects  to  be  registered  is: 

a)  Application-process-tities; 

b)  Application-entity-tities; 

c)  Abstract  syntaxes; 

d)  Transfer  syntaxes; 

e)  Application-contexts; 

f)  MHS; 


1) 

ADMD  names; 

2) 

PRMD  names; 

3) 

Organization  names; 

4) 

Encoded  information  types; 

5) 

Extended  body  part  types; 

6) 

Extensions; 

7) 

etc.; 

g)  Object  identifier  values; 

h)  ASN.1  modules; 

i)  Directory; 

1)  Relative  distinguished  names; 

2)  Attribute  types; 

3)  Attribute  syntaxes; 
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4)  Object  classes; 

5)  Encryption  algorithms; 

6)  etc.; 

j)  VT; 

1)  Profiles; 

2)  Reference  Information  objects; 

3)  etc.; 

k)  Network  management  objects; 
I)  Network  layer  addresses; 
m)  System  titles; 
n)  FTAM; 

1)  Document  types; 

2)  Constraint  sets; 

3)  etc.; 

o)  etc. 

The  OIW  Registration  Authority  shall  only  administer  information  objects  created  by  the  OIW  Agreements 
Document  that  are  kJentified  by  the  ASN.1  type  OBJECT  IDENTIFIER.  Figure  1  Illustrates  the  structure  of 
the  object  kJentifier  component  value  for  OIW. 

(  iso  identified-organization    oiw  (14)  ) 
iso(l) 

i  dent  i  £  i  ed-or gimi  zat  i  on ( 3 ) 

oiw(14) 

Figure  1  -  Structure  of  Object  Identifier  for  OIW. 

As  an  example  figure  2  shows  the  object  Identifier  component  value  for  an  example  object. 
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(  iso    identified-organization  oiw(14)  rasig(13) 

example ( 0 ) } 

iso(l) 

i  dent  i  £  i  ed-or gani  zat  ion ( 3 ) 

rasig(13) 

ex2unple(0) 

Figure  2  -  Structure  of  an  Object  Identifier  for  an  Example  Object  for  the  Registration  Authority  SIG 

of  OIW. 

The  ISO  6523  Registration  Authority  has  assigned  an  Intemationai  Code  Designator  (ICD)  value  of  14  to 
OIW,  and  OIW  has  assigned  a  unique  object  identifier  component  value  to  each  SIG.  The  assigned  object 
ID  values  for  the  OIW  and  for  each  SIG  are  in  Annex  A.  The  assignment  of  values  below  each  SIG  in  the 
object  identifier  tree  is  the  responsibility  of  that  SIG. 


4     Registration  Procedures  for  Object  identifiers 

This  clause  specifies  the  responsibilities  of  each  SIG  and  the  procedures  to  be  followed  for  the  registration 
of  information  objects,  and  submission  to  the  OIW  Plenary. 

When  an  OIW  SIG  defines  an  information  object  the  SIG  shall  register  the  object  identifier.  The  registered 
value  shall  be  incorporated  into  the  appropriate  OIW  Agreements  Document  as  a  result  of  a  positive  ballot 
response  of  the  OIW  Plenary. 


4.1      SIG  Registration  Autliorization 

An  OIW  SIG  is  authorized  by  its  charter  and  the  scope  of  its  work  to  submit  a  registration  request  to  the 
OIW  Plenary. 


4.2      SIG  Registration  Authority  Function  and  Duties 

The  SIG  Chair  is  responsible  for  the  assignment,  recording  and  maintenance  of  the  SIG's  registered  objects. 
The  SIG  Chair  may  appoint  a  specific  person  to  carry  out  the  SIG  duties  and  responsibilities. 
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4.3      Requirements  for  Information  Object  Registration 


4.3.1       Assignment  of  Object  Identifier  Component  Values 

Each  SiG  shall  register  an  object  identifier  component  value  for  each  object's  technical  definition.  The 
NameAndNumberForm  of  the  ObjIdComponent  specified  in  ISO  8824/CCnT  X.208  is  used  exclusively.  This 
form  comprises  an  ASN.1  identifier  and,  significantly,  a  NumberForm. 

It  is  suggested  that  the  SiG  assign  a  monotonically  increasing  integer  to  the  NumberFomi  at  any  given  level. 
To  the  significant  root  the  SIG  shall  add  a  assigned  object  identifier  component  value  that  shall  be  unique. 
An  example  of  an  object  identifier  created  by  the  RASIQ  is  shown  as  follows: 

{iso(1)identified-organization(3)  oiw(14)  rasig(13)  example(0)} 

Here  rasig  is  the  SIG  identifier  and  13  is  the  NumberForm  assigned  by  the  OIW  Registration  Authority  (see 
Annex  A);  example  is  the  identifier  and  0  is  the  NumberForm  assigned  by  the  RASIG. 


4.3.2       Proposal  of  Object  and  identifier  to  Plenary 

Registration  of  an  object  identifier  and  its  definition  is  proposed  by  inclusion  of  the  object  identifier  and  its 
definition  in  the  OIW  "Working  Implementation  Agreements"  document. 


4.3.3       Completion  of  Registration  Procedure 

Registration  of  an  object  identifier  and  its  definition  is  completed  upon  Plenary  vote  to  move  "Working 
Implementation  Agreements"  text  which  contains  the  object  identifier  and  its  definition  to  the  "Stable 
Implementation  Agreements"  document. 


4.3.4       Changes  and  Revisions  to  tlie  information  Object  Registration 

Neither  the  technical  definition  nor  the  object  identifier  shall  be  changed  or  modified  after  registration  i.e., 
after  the  definitions  and  their  identifiers  have  been  voted  into  the  "Stable  Implementation  Agreements" 
document. 
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4.4     Register  Index 

Each  SIQ  shall  maintain  an  index  of  object  identifiers  that  point  to  the  technical  definitions  of  the  respective 
objects  in  the  OIW  Agreements  Docurnent  Tfie  Indoc  shall  appear  in  the  appropriate  part  annexes  of  the 
OIW  Agreements  Document 


Table  1  -  index  Entry  Example 


Object  Mwilifter 

Reference 

iso  identified-organization 

4.3.1 

olw(14)  rasig(13)  example(0) 
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Annex  A  (normative) 

Assignments  to  Workshop  Organizations 


Table  2  -  Identifier  Ass 

Bnments 

Idantifiar 

Valu* 

AftftlanAd  To 

Assigned  By 

oiw 

14 

OIW 

ISO  6523  RA 

llsig 

1 

SIG 

OIW 

nmsig 

2 

SIG 

OIW 

secsig 

3 

SIG 

niiAi 

UIW 

tpsig 

4 

SIG 

OIW 

ftamsig 

5 

SIG 

OIW 

mhsig 

6 

SIG 

OIW 

dssig 

7 

SIG 

OIW 

ulsig 

8 

SIG 

OIW 

rdasig 

9 

SIG 

OIW 

mmssig 

10 

SIG 

OIW 

odasig 

11 

SIG 

OIW 

vtsig 

12 

SIG 

OIW 

rasig 

13 

SIG 

OIW 

hcsig 

14 

SIG 

OIW 

ctsig 

15 

SIG 

OIW 
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Annex  B  (normative) 

Status  of  1987  and  1988  Ad-hoc  Object  Identifiers 

In  the  1987  and  1988  versions  of  the  Stable  Implementation  Agreements,  a  number  of  OlW-speclfied 
information  objects  are  assigned  object  identifiers.  ' 

OSI  requires  names  and  addresses,  e.g..  object  identifiers,  be  globally  unambiguous.  This  chapter  specifies  | 
object  identifier  component  values  which  are  globally  unambiguous.  Other  chapters  in  this  document 
specify  the  correct  object  identifiers  to  be  used  when  referencing  OlW-specified  information  objects.  ' 

The  use  of  the  1987  and  1988  OlW-specified  object  identifiers  is  deprecated.  Newly  defined  objects  shall 
use  the  new  OIW  Identifier. 
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Annex  C  (informative) 

Guidelines  for  Registering  Clianges  to  Tectinicai  Objects 

Part  6  of  the  OIW  Agreements  document  describes  the  process  for  registering  technical  information  objects 
that  are  defined  in  the  development  of  OIW  implementation  agreements.  However,  the  process  does  not 
describe  a  criteria  for  determining  when  a  change  to  an  object  definition  is  of  sufficient  magnitude  to  require 
registration  of  a  new  object  with  a  new  01 D.  Such  criteria  would  t>e  useful  when  changes  are  proposed  to 
technical  object  definitions  that  have  already  been  registered. 

The  registration  procedures  for  technical  information  objects  in  OIW  implementation  Agreements  assumes 
that  each  object  is  uniquely  different  in  particular  ways  from  all  other  registered  technical  information  objects, 
and  requires  that  there  is  exactly  one  definition  for  each  registered  object  identifier  (OID).  Therefore,  when 
an  object  definition  is  to  be  changed,  it  must  receive  a  new  OID  if  the  change  is  "sufficiently  significant,"  in 
order  to  signal  to  all  concerned  parties  that  something  significant  has  been  changed. 


The  purpose  of  this  tutorial  section  is  to  provide  a  guide  for  the  evaluation  of  proposed  clianges  to  the 
definition  of  a  technical  object.  Many  of  the  changes  will  fall  in  a  gray  area  between  an  obvious  "editorial 
change"  with  no  change  to  the  operational  characteristics  of  the  registration  and  "significant  change"  that 
will  require  the  requested  change  to  be  registered  as  a  new  technical  object  with  a  new  Object  Identifier 
(OID). 

These  guidelines  are  presented  to  assist  in  providing  a  consistent  approach  for  reviewing  requests  and 
making  changes  to  any  registered  technical  object. 


C.I     Evaluating  Registered  Technical  Objects 

Technical  objects  in  the  OIW  registers  include  a  functional  definition  describing  the  object,  its  states  and  the 
actions  that  can  change  the  object's  states.  The  definition  and  actions  of  the  object  are  usually  presented 
as  descriptive  text,  while  the  state  may  be  defined  by  a  data  structure  and  a  set  of  values  such  as  constants 
or  ranges,  having  a  particular  syntax.  It  should  be  recognized  as  stated  above  that  modifying  or  deleting 
one  or  more  parts  of  the  definition  may  not  be  of  sufficient  importance  to  require  the  registration  of  the 
registered  technical  object  under  another  identifier  (OID). 

For  example,  we  should  note  that  sometimes  a  change  may  be  desired  to  specifically  reduce  confusion  that 
stems  from  different  interpretations  of  a  given  definition.  In  this  case,  the  change  might  require  some 
implementations  to  be  modified  to  conform  to  a  chosen  interpretation,  but  who  is  to  say  that  the  definition 
was  changed,  versus  saying  that  the  original  intent  was  finally  made  clear?  It  is  a  matter  of  judgement  by 
the  responsil3le  OIW  SIG  to  decide  whether  a  new  OID  should  be  assigned  in  this  case,  or  not. 

When  a  change  is  sufficiently  significant  to  require  a  new  OID,  then  the  old  object  must  remain  unchanged 
with  its  old  OID. 
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Review  criteria  must  consider  the  relative  importance  of  the  parts  of  the  technical  object  definition  that  are 
affected  by  a  change  before  determining  whether  to  approve  the  proposed  change.  Deciding  not  to  accept 
a  proposed  change  may  result  in  a  need  to  create  a  new  technical  object  very  similar  to  the  one  being 
reviewed. 


C.2     A  Registration  Review  Criteria 

The  significant  components  of  the  technical  definition,  to  which  a  criteria  can  be  applied  include  the  text 
description  of  the  technical  object,  the  definitions  of  the  state  values,  and  the  definitions  of  the  data 
structures.  The  criteria  is  not  intended  to  be  regulatory  In  nature,  but  to  provide  some  direction  in  reviewing 
each  of  the  three  components  when  evaluating  change  requests  for  registered  technical  objects. 


C.2.1       The  Technical  Object  Description 

Does  the  proposed  definition  change  or  require  a  uniquely  different  set  of  functions  or  state  conditions,  or 
does  the  proposed  change  alter  the  relationship  between  functions  of  the  registered  object? 

if  the  proposed  definition  change  adds  another  function  or  creates  another  state,  or  modifies  the  relationship 
between  functions  or  state  conditions  of  the  object,  or  deletes  a  defined  function  or  state  condition  then  the 
proposed  change  should  be  registered  as  a  new  technical  object  with  a  new  01 D,  provided  that  the 
proposed  change  would  have  a  significant  impact  upon  the  implementation  or  operation  of  the  technical 
object  when  changed. 

Editorial  changes  can  be  made  to  correct  grammatical  errors  or  to  improve  clarity,  without  changing  the 
definition.  For  changes  that  require  additions  or  deletions  of  text  to  the  definition,  an  evaluation  must  be 
made  to  determine  if  the  changes  when  applied  are  optional  or  will  apply  only  to  a  local  implementation, 
or  are  extensive  enough  to  require  a  new  implementation. 

Deciding  what  change  means  with  respect  to  the  functional  definition  is  a  subjective  view  and  will  require 
that  each  SIG  establish  some  guidelines  for  its  particular  object  types.  Consistency  of  application  of  a 
registration  policy  within  each  SIG  would  be  most  helpful  to  the  process. 

One  approach  is  to  rule  that  any  change,  other  than  a  spelling  or  grammar  change  requires  a  new  technical 
object  registration.  However,  the  consequence  of  such  a  rule  would  be  a  large  number  of  registered 
technical  objects  with  very  similar  definitions  that  can  create  considerable  confusion  for  implementors.  The 
opposite  position  is  to  treat  any  change  to  the  functional  description  as  an  editorial  change,  and  only 
changes  to  the  other  criteria  lil<e  the  state  values  or  data  structures  are  evaluated  to  make  a  decision  about 
registration  of  the  changed  object  as  a  new  technical  object. 

Between  the  two  is  a  more  acceptable  view  that  provides  for  the  evaluation  of  the  proposed  change  to 
decide  whether  the  change  is  editorial  only,  NOT  affecting  implementation;  or  if  it  is  a  change  in  functionality 
that  MAY  affect  implementation.  If  it  does  NOT  affect  implementation,  then  it  is  an  editorial  change.  If  it  MAY 
affect  the  implementation,  then  the  change  requested  should  be  evaluated  for  registration  as  a  new  technical 
information  object  with  a  new  01 D. 
An  Example: 
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Change  #1.  A  given  registered  object  indudes  a  range  of  values  for  a  particular  attribute  called  TIMEOUT. 
It  includes  the  following  two  fcicts: 

a)  a  definition  of  the  TIMEOUT  attribute; 

b)  the  range  of  values  for  the  TIMEOUT  attribute. 

If  the  range  of  the  TIMEOUT  attribute  is  changed  from  10..100  to  be  10..1000,  It  is  possible  that  the  change 
is  not  significant  enough  to  warrant  a  new  registration,  if  the  parameter  is  only  applied  ioceilty.  (We  wll 
assume  that  this  is  the  case  for  this  example.) 

Change#2.  Suppose  the  same  attribute  Is  to  be  deleted.  Then  some  assessment  is  needed,  regarding  the 
impact  of  the  change  to  tho  glot>al  operational  environment  in  which  the  technical  object  is  to  function,  to 
determine  if  a  new  registration  is  required  with  a  new  OID. 

The  relative  significance  of  the  two  changes  to  the  operational  requirements  are  dear  (given  our 
assumptions  here)  in  these  two  cases.  Changing  the  values  of  the  range  of  the  TIMEOUT  parameter  is  a 
relatively  minor  change  which  affects  only  local  operation.  Depending  on  other  operational  considerations, 
and  the  relation  of  the  TIMEOUT  to  other  facts  about  the  technical  object  it  could  be  changed  without  a  new 
registration.  But  the  elimination  of  the  TIMEOUT  attribute  altogether  would  be  much  more  significant,  and 
more  than  lil<ely  require  a  new  registration,  since  current  implementations  would  be  expecting  the  existence 
of  such  an  attribute  in  any  operating  environment,  and  future  implementations  would  not  indude  it. 


C.2.2      Evaluating  the  State  Values 

Within  the  registered  technical  ot)ject  description  there  may  be  a  numt)er  of  constants,  ranges  of  values,  and 
syntaxes  specifically  defined  for  the  object.  They  are  all  subject  to  change.  The  evaluation  criteria  applied 
to  requests  for  changes  to  state  values  has  to  consider  the  l<ind  of  operation  that  the  technical  object  is 
performing. 

EXAMPLE:  The  range  of  accepted  values  is  changed  from  1  -1 28  to  0-1 27,  or  the  default  value  of  a  parameter 
is  clianged  from  32  to  128. 

Understanding  the  implications  of  what  is  changing  helps  to  measure  the  impact  of  the  proposed  changes. 
The  shift  of  the  range  from  1-128.  to  0-127  could  be  trivial,  depending  on  the  scope  of  its  use  and  would 
not  alone  necessarily  wanant  a  new  registration.  However  to  change  a  default  value  from  32  to  128  (if  the 
attribute  applies  to  the  availability  or  limit  of  some  external  system  or  network  resource)  would  dearly  be 
cause  for  much  concem  over  hc»w  the  change  impacts  implementations  of  the  technical  object. 


C.2.3      Evaluating  the  Data  Structure 

Each  technical  Information  object  may  have  one  or  more  data  structures  defined  within  the  description  of 
the  object.  Changes  can  be  made  to  the  data  structures  in  a  number  of  ways.  Data  field  sizes  can  change, 
and  the  number  of  data  fields  can  change.  As  with  the  state  values,  they  should  be  considered  in  a  very 
broad  sense  that  is  within  the  definition  and  the  extent  of  the  use  of  these  data  structures  beyond  local 
system  usage. 
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One  must  be  aware  that  ail  syntactical  changes  in  a  technical  definition  need  not  be  mandatory;  they  may 
be  optional.  Given  that  the  changes  are  mandatory,  they  are  most  lil<ely  to  affect  every  implementation,  and 
are  going  to  impact  the  functioning  of  the  object.  Such  a  case  would  warrant  that  the  change  t>e  registered 
as  a  new  technical  object. 

EXAMPI^:  A  defined  data  field  is  changed  from  3  octets  to  4  and  another  field  is  reduced  from  2  octets  to 
1  octet. 

Changing  the  data  structure  is  prot)at>ly  the  clearest  case  of  a  requirement  to  change  an  implementation. 
One  must  be  aware  that  all  syntactical  changes  in  technical  definitions  need  not  be  mandatory,  they  may 
be  optional.  But  if  the  changes  are  mandatory,  they  will  most  likely  affect  every  implementation,  and  in  such 
a  way  that  they  will  not  interoperate  properly  with  old  implementations.  Such  cases  warrant  that  the  change 
be  registered  as  a  new  technical  object  with  a  new  OID. 

With  respect  to  applying  these  criteria,  it  should  be  emphasized  that  it  is  most  important  to  be  consistent 
in  making  subjective  judgments  concerning  changes  to  registered  technical  objects,  rather  than  being 
"correct." 

There  may  be  more  than  one  interpretation  or  "correct"  view  regarding  any  proposed  change,  but  if  the 
application  of  the  guidelines  are  consistent,  then  the  implementations  are  more  likely  to  be  consistent. 


C.3     The  Change  Process 

Responsibility  for  evaluating  the  change  requests  is  assigned  to  each  SIG.  The  SIG  makes  its  determinations 
by  voting  on  changes  to  each  registered  object  as  it  is  defined  in  the  SIG  text  in  the  OIW  Implementation 
Agreements  Documents.  Any  SIG  approved  changes  must  also  be  voted  in  the  OIW  Plenary  using  the  rules 
of  the  SIG  and  the  Plenary. 

An  object  definition  in  a  Working  Agreement  text  is  not  registered  until  it  has  been  voted  into  the  Stable 
Agreements  Document,  so  it  is  possible  to  modify  an  as  yet  "unregistered"  object  in  the  Working  Agreements 
Document. 
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NOTE  -  The  classification  schema  used  in  this  chapter  (see  table  7)  pre-dated  TR  10  000  and  was  the 
basis  of  extensive  hamnonization,  as  such:  No  attempt  will  be  made  to  align  this  chapter  with  TR  10  000. 


0  Introduction 

This  is  an  implementation  agreement  developed  by  the  Implementor's  Worlcshop  sponsored  by  the 
National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between 
devices  manufeictured  by  different  vendors.  This  agreement  is  based  on,  and  employs  protocols 
developed  in  accord  with,  the  OSI  Reference  Model.  While  this  agreement  Introduces  no  new  protocols, 
it  eliminates  ambiguities  in  interpretations. 

This  is  an  implementation  agreement  for  a  Message  Handling  System  (MHS)  based  on  the  X.400-serie8 
of  Recommendations  (1984)  and  Version  5  of  the  X.400  Series  Implementor's  Guide  from  the  CCITT.  It  is 
recommended  that  product  vendors  consult  later  versions  of  this  guide.  Figure  1  displays  the  layered 
strudure  of  this  agreement 

This  agreement  can  be  used  over  any  Transport  protocol  dass.  In  particular,  this  MHS  agreement  can 
be  used  over  the  Transport  protocol  dass  0  used  over  COTT  X.25,  described  in  dause  5.2  of  this 
document.  In  addition,  tills  MHS  agreement  can  be  used  over  the  Transport  profiles  used  in  support  of 
MAP  (Manufacturing  Automation  Protocol)  or  TOP  (Technical  and  Office  Protocols).  Note  that  the  MAP 
or  TOP  environment  must  support  the  reduced  Basic  Activity  Subset  (BAS)  as  defined  in  X.410. 

The  UAs  and  MTAs  require  access  to  directory  and  routing  services.  A  Directory  Service  is  to  be 
provided  for  each  (vendor-specific)  domain.  Except  insofeir  as  they  must  be  capable  of  providing 
addressing  and  routing  descrit)ed  hereunder,  these  services  and  associated  protocols  are  not  described 
by  this  agreement 


User  Agent  Layer 

CCITT  X.420 

Message  Transfer  Agent  Layer 

CCITT  X.411 

Reliable  Trimsfer  Service  Layer 

CCITT  X.410 

Presentation  Layer 

CCITT  X.410  Sec.  4.2 

Session  Layer 

See  clause  5.9 

Figure  1  -  The  layered  structure  of  this  implementation  agreement. 
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1  Scope 

This  agreement  applies  to  Private  Management  Domains  (PRMDs)  and  Administration  Management 
Domains  (ADMDs).  Four  tx)undary  interfaces  are  specified: 

a)  PRMDtoPRMD, 

b)  PRMDtoADMD. 

c)  ADMD  to  ADMD,  and 

d)  MTA  to  MTA  (within  a  PRMD.  e.g..  for  MTAs  from  different  vendors). 

In  case  A.  the  PRMDs  do  not  make  use  of  MHS  sen/ices  provided  by  an  ADMD.  In  cases  B  and  C,  UAs 
associated  with  an  ADMD  can  be  the  source  or  destination  for  messages.  Furthermore,  in  cases  A  and 
B,  a  PRMD  can  serve  as  a  relay  t>etween  MDs.  and  in  cases  B  and  C  an  ADMD  can  serve  as  a  relay 
between  MDs.  Figure  2  illustrates  the  interfaces  to  which  the  agreement  applies. 

X.400  protocols  other  than  the  Message  Transfer  Protocol  (PI)  and  the  Interpersonal  Messaging 
Protocol  (P2)  are  beyond  the  scope  of  this  agreement.  Issues  arising  from  the  use  of  other  protocols  or 
relating  to  PI  components  in  support  of  other  protocols  are  outside  the  scope  of  this  document.  This 
agreement  describes  the  minimum  level  of  services  provided  at  each  interface  shown  in  figure  2. 
Provision  for  the  use  of  the  remaining  services  defined  in  the  X.400  Series  of  Recommendations  is 
outside  the  scope  of  this  document. 

With  the  exception  of  intra  domain  connections,  this  agreement  does  not  cover  message  mchange 
between  communicating  entities  within  a  domain  even  if  these  entities  communicate  via  PI  or  P2. 
Bilateral  agreements  between  domains  may  be  implemented  in  addition  to  the  requirements  stated  in 
this  document.  Conformance  to  this  agreement  requires  the  ability  to  exchange  messages  without 
use  of  bilateral  agreements. 
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PRMD  ■  Private  Manageaent  Doaain 

MyHD  *  Administration  Hanageaent  Domain 
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Figure  2  -  This  agreement  applies  to  the  interface  between:  (A)  PRIMD  and  PRMD;  (B)  PRMD  and 
ADMD;  (C)  ADMD  and  ADMD;  and  (D)  MTA  and  MTA. 


2    Normative  references 

CCtrr  Recommendation  X.121  (1988).  International  Numbering  Plan. 

com  Recommendation  X.400.  (Red  Book,  1984).  Message  Handling  Systems:  System  Model-Service 
Elements. 

CX^ITT  Recommendation  X.401.  (Red  Book.  1984).  Message  l-iandling  Systems:  Basic  Service  Elements 
and  Optk>nal  User  Facilities. 

CCITT  Recommendation  X.408,  (Red  Book,  1984).  Message  Handling  Systems:  Encoded  Information 
Type  Converston  Rules. 

CCITT  Recommendation  X.409,  (Red  Book.  1984).  Message  Handling  Systems:  Presentation  Transfer 
Syntax  and  Notatk>n. 

CCITT  Recommendation  X.410,  (Red  Book.  1984).  Message  Handling  Systems:  Remote  Operattons  and 
Reliable  Transfer  Server. 

CCITT  Recommendation  X.411.  (Red  Book.  1984),  Message  Handling  Systems:  Message  Transfer  Layer. 

can  Recommendation  X.420.  (Red  Book,  1984).  MessageHandling  Systems:  Interpersonal  Messaging 
User  Agent  l^yer. 

CCin  Recommendation  X.430.  (Red  Book.  1984).  Message  Handling  Systems:  Access  Protocol  for 
Teletex  Terminals. 
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3  Status 

This  version  of  the  X.400  based  Message  Handling  System  implementation  agreements  was  completed 
on  Decemt>er  16,  1988.  No  further  enhancements  will  be  made  to  this  version.  See  the  next 
clause-Errata. 

4  Errata 


5     PRMD  to  PRMD 


5.1  Introduction 

This  clause  is  limited  in  scope  to  issues  arising  from  the  direct  connection  (interface  A  in  figure  2)  erf  two 
PRMDs.  "Direct"  means  that  no  ADMD  or  relaying  PRMD  provides  MIHS  services  to  facilitate  message 
interchange.  "Direct"  does  not  exclude  those  instances  for  which  Administrations  happen  to  be  ADMDs 
but  are  not  providing  X.400  services,  that  is,  they  are  used  only  to  provide  lower  layer  services  such  as 
X.25.  Figure  3  schematically  represents  the  scope  of  this  clause. 

These  issues  relate  to  the  use  of  the  UAL  (User  Agent  Layer)  and  MTL  (Message  Transfer  Layer) 
services,  protocol  elements,  recommended  practices  and  constraints.  In  particular,  this  clause  addresses 
the  PI  and  P2  protocols  and  their  related  services  in  a  direct  connection  environment.  This  clause 
descritDes  the  minimum  level  of  services  provided  by  a  PRMD.  Provision  for  the  use  of  the  remaining 
services  defined  in  the  X.400  Series  of  Recommendations  is  beyond  the  scope  of  this  clause. 
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Figure  3  •  Interconnection  of  private  domains. 


5.2     Service  elennents  and  optional  user  facilities 

This  clause  identifies  those  service  elements  and  optional  user  facilities  that  must  t^e  provided  in  support 
of  PI  and  P2. 


5.2.1       Classification  of  support  for  services 

The  classification  of  UA  and  MT-Service  elements  is  used  to  define  characteristics  of  equipment. 
Equipment  can  claim  SUPPORT  or  NON-SUPPORT  of  a  Service;  in  the  case  of  UA-service  elements,  a 
separate  classification  is  given  for  Origination  and  Reception. 

The  service  provider  is  defined  as  the  entity  providing  the  service,  in  this  case,  the  MTL  or  the  UAL  The 
service  user  is  either  the  MHS  user  or  the  UAL  The  classification  of  provider  and  user  relates  to  the 
sut)layer  for  which  the  service  element  is  defined. 


5.2.1.1        Support  (S) 

Support  means: 

a)  The  service  provider  makes  the  service  element  availatile  to  the  service  user,  and 

b)  The  service  user  gives  adequate  support  to  the  MHS  to  lnvol<e  the  service  element  or  mal<es 
information  associated  with  the  service  element  available. 
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Support  for  Origination  means  that: 

a)  The  service  provider  makes  the  service  element  available  to  the  service  user  for  Invocation, 
and 

b)  The  service  user  gives  adequate  support  to  the  end  user  of  the  MHS  to  invoke  the  service 
element. 

Support  for  Reception  means  that: 

a)  The  service  provkJer  makes  infomnation  associated  with  the  service  element  available  to  the 
service  user. 

NOTE  -  A  UA-  or  MT-service  element  can  carry  infonnation  from  originator  to  recipient  only  if: 

b)  the  service  element  is  available  to  the  originator. 

c)  the  service  element  is  available  to  the  recipient,  and 

d)  all  intermediate  steps  carry  the  information. 

5.2.1.2  Non  Support  (N) 

This  means  that  the  service  provider  is  not  required  to  make  the  service  element  available  to  the  service 
user.  However,  the  service  provkJer  should  not  regard  the  occurrence  of  the  corresponding  protocol 
elements  as  an  error  and  should  be  able  to  relay  such  elements.  Implementations  nfiaking  a  profile 
available  should  indicate  deviations  (additions  or  deletions)  with  respect  to  the  requirement  in  the  profile. 

5.2.1.3  Not  Used  (N/U) 

This  means  that  although  the  Recommendation  allows  this  service  element,  this  profile  does  not  use  It. 

5.2.1.4  Not  Applicable  (N/A) 

This  means  that  this  sen/ice  element  does  not  apply  In  this  particular  case  (for  originator  or  recipient). 
5.2.2       Summary  of  supported  services 

Within  a  PRMD,  a  User  Agent  must  support  all  P2  BASIC  iPM  Services  (X.400)  and  all  P2  ESSENTIAL 
IPM  Optional  user  facilities  (X.401)  subject  to  the  qualifiers  listed  in  annex  A. 

Within  a  PRMD,  a  MTA  must  support  all  BASIC  MT  Sen/ices  (X.400)  and  all  ESSENTIAL  MT  optional 
user  facilities  (X.401)  subject  to  the  qualifiers  listed  in  annex  A. 
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No  support  is  required  of  the  additional  optional  user  tecilities  of  X.401. 

5.2.3      MT  service  elements  and  optional  user  facilities 

Tables  1  through  3  show  the  Message  Transfer  (MT)  service  elements  and  optional  user  facilities. 


Table  1  -  Basic  MT  service  elements 


Service  Elements 

Support  (S)  or 
Non-support  (N) 

Access  Memagement 

N/U^ 

Content  Type  Indication 

S 

Converted  Indication 

S 

Delivery  Time  Steuap  Indication 

s 

Message  Identification 

s 

Non-delivery  Notification 

s 

Original  Encoded  Information  Types  Indication 

s  , 

Registered  Encoded  Information  Types 

N/U^ 

Submission  Time  Steunp  Indication 

s 

Notes 

1    Not  applicable  to  co-resident  UA  and 

MTA. 
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Table  2  -  MT  optional  user  facilities  provided  to  the  UA-selectable  on  a  per-message  basis 


MT  Optional  User  Facilities 


Support  (S)  or 
Categorization    Non-support  (N) 


Alternate  Recipient  Allowed 

E 

S 

Conversion  Prohibition 

E 

s 

Deferred  Delivery 

E 

N 

Deferred  Delivery  Cancellation 

E 

N 

Delivery  Notification 

E 

s 

Disclosure  of  Other  Recipients 

E 

N 

Explicit  Conversion 

A 

N 

Grade  of  Delivery  Selection 

E 

S 

Multi-destination  Delivery 

E 

s 

Prevention  of  Non-delivery  Notification 

A 

N 

Probe 

E 

N 

Return  of  Contents 

A 

N 

Legend 

E:    Essential  optional  user  facility. 
A:    Additional  optional  user  facility. 


Notes 

2  A  local  facility  subject  to  qualifiers  in  annex  A. 

3  Support  not  required  for  an  originating  MT  user;  support  nust  be 
provided  for  recipient  MT  users. 

4  Subject  to  qualifiers  in  annex  A. 


Table  3  -  MT  optional  user  facilities  provided  to  tlie  UA  agreed  for  any  contractual  period  of  Time 


MT  Optional  User  Facilities  Categorization 

Support  (S)  or 
Non-Support  (N) 

Alternate  Recipient  Assignment  A 
Hold  for  Delivery  A 
Implicit  Conversion  A 

N 

NAJ 

N 

Legend 

A:    Additional  optional  user  facility. 

5.2.4       \PM  service  elements  and  optional  user  facilities 

Tables  4  through  6  show  the  IPM  service  elements  and  optional  user  facilities. 
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Table  4  -  Basic  IPM  service  elements 


Service  Elements 

Origination 
by  UAs 

Reception 
by  UAs 

Access  Management 

N/u5 

N/U^ 

Content  Type  Indication 

S 

S 

Converted  Indication 

N/A 

S 

Delivery  Time  Steunp  Indication 

N/A 

S 

Message  Identification 

S 

S 

Non-delivery  Notification 

S 

N/A 

Original  Encoded  Information 

s 

S 

Types  Indication 

Registered  Encoded  Information  Types  N/A 

N/a5 

Submission  Time  Stamp  Indication 

s 

S 

IP-message  Identification 

s 

S 

Typed  Body 

s 

S 

Notes 

5    Does  not  apply  to  co-resident 

UA  and  MTA. 

Table  5  -  IPM  optional  facilities  agreed  for  a  contractual  period  of  time 


Support  (S)  or 

Service  Elements  Categorization 

Non-Support  (N) 

Alternate  Recipient  Assignment  A 

n 

Hold  for  Delivery  A 

N 

Implicit  Conversion  A 

N 
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Table  6  -  IPM  optional  user  facilities  selectable  on  a  per-message  basis 


Origination 

Reception 

IPM  Optional  User  Facilities 

by  UAs 

by  UAs 

Alternate  Recipient  Allowed 

A 

(N) 

A  (N) 

Authorizing    Users  Indication 

A 

(N) 

E  (S) 

Auto-forwarded  Indication 

A 

(N) 

E  (S) 

oxinu  K^opY  Kecipienw  xnaicakion 

A 

(N) 

E  (S) 

Body  Part  Encryption  Indication 

A 

(N) 

E  (S) 

Conversion  Prohibition 

E 

(S) 

E  (S) 

Cross-referencing  Indication 

A 

(N) 

E  (S) 

Deferred  Delivery 

E 

(N)^ 

N/A 

Deferred  Delivery  Cancellation 

A 

(N/U)^ 

N/A 

Delivery  Notification 

E 

(S) 

N/A 

Disclosure  of  Other  Recipients 

A 

(N) 

E  (S) 

Expiry  Date  Indication 

A 

(N) 

E  (S) 

Explicit  Conversion 

A 

(N) 

N/A 

A 

(N) 

E  (S) 

Grade  of  Delivery  Selection 

E 

(S) 

E  (S) 

Importance  Indication 

A 

(N) 

E  (S) 

Mult i -destination  Delivery 

E 

(S) 

N/A 

Multi-part  Body 

A 

(N) 

E  (S) 

Non-receipt  Notification 

A 

(N) 

A  f N) 

Obsoleting  Indication 

A 

(N) 

E  (S) 

Originator  Indication 

E 

(S) 

E  (S) 

Prevention  of  Non-delivery  Notification 

A 

(N) 

N/A 

Primary  and  Copy  Recipients  Indication 

E 

(S) 

E  (S) 

Probe 

A 

(N) 

N/A 

Receipt  Notification 

A 

(N) 

A  (N) 

Reply  Request  Indication 

A 

(N) 

E  (S) 

Replying  IP-message  Indication 

E 

(S) 

E  (S) 

Return  of  Contents 

A 

(N) 

N/A 

Sensitivity  Indication 

A 

(N) 

E  (S) 

Subject  Indication 

E 

(S) 

E  (S) 

Notes 

6    A  local  facility  subject  to  qualifiers  in  annex 

A. 

5.3      X.400  protocol  definitions 

This  clause  reflects  the  agreements  of  the  OIW  regarding  PI  and  P2  protocol  elements. 
5.3.1       Protocol  classification 

The  protocol  classifications  are  defined  in  table  7. 
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1)  DNSDPPQRTED  =  X 

These  elements  may  be  generated,  but  no  specific  processing  should 
be  expected  in  a  relaying  or  delivering  domain.  A  relaying  domain 
must  at  least  relay  the  semimtics  of  the  element.  The  absence  of 
these  elements  should  not  be  assumed,  in  a  relaying  or  delivering 
domain,  to  convey  any  signif icemce. 

2)  SUPPORTED  =  H 

These  elements  may  be  generated.  However,  implementations  are  not 
required  to  be  able  to  generate  these  elements.  Appropriate 
actions  shall  be  taken  in  a  relaying  or  delivering  domain. 

3)  GENERATABLE  =  G 

Implementations  must  be  able  to  generate  and  handle  these  protocol 
elements,  although  they  are  not  necessarily  present  in  all 
messages  generated  by  implementations  of  this  profile. 
Appropriate  actions  shall  be  taken  in  a  relaying  or  delivering 
domain. 

4)  REQUIRED  =  R 

Implementations  of  this  profile  must  always  generate  this  protocol 
element.  However,  its  absence  cannot  be  regarded  as  a  protocol 
violation  as  other  MHS  implemnntations  may  not  require  this 
protocol  element.  Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 

5)  MANDAT(»T  =  M 

This  must  occur  in  each  message  as  per  X.411  or  X.420  as 
appropriate;  absence  is  a  protocol  violation.  Appropriate  actions 
shall  be  taken  in  a  relaying  or  delivering  domain. 


5.3.2      General  statements  on  pragmatic  constraints 

Where  a  protocol  element  Is  defined  as  a  choice  of  Numeric  String  and  Printable  String  (i.e., 
Administration  Domain  Name  and  Private  Domain  Identifier),  then  a  numeric  value  encoded  as  a 
printable  string  is  equivalent  to  the  same  value  encoded  as  a  numeric  string.  This  does  not  apply  to  the 
Country  Name  protocol  element. 

The  maximum  number  of  recipients  in  a  single  MPDU  is  32K  - 1  (that  is,  32767).  However,  no  individual 
limits  on  the  number  of  occurrences  (recipients)  are  placed  on  the  following  protocol  elements: 
Authorizing  Users,  Primary  Recipients,  Copy  Recipients,  Blind  Copy  Recipients,  Obsoletes  and  Cross 
References.  Additionally,  there  is  no  limit  on  the  number  of  Reply  to  Users.  This  is  a  local  matter  for  the 
originating  system. 

Use  of  strings.  A  Printable  String  is  defined  in  terms  of  the  number  of  characters,  which  is  the  same 
number  of  octets.  For  T.61  strings  the  number  of  octets  is  twice  the  number  of  characters  specified. 

The  ability  to  generate  maximum  size  elements  is  not  required,  with  the  exception  of  the  component 
fields  in  the  Standard  Attribute  List,  in  which  case  it  is  required. 
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5.3.3  MPDU  size 

The  following  agreements  govern  the  size  of  MPDUs: 

a)  All  MTAEs  must  support  at  least  one  MPDU  of  at  least  2  megabyte,  and 

b)  The  size  of  the  largest  MPDU  supported  by  a  UAE  is  a  local  matter. 

5.3.4  PI  protocol  elements 

Table  8  contains  Protocol  Elements  and  their  classes. 
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Table  8  -  PI  protocol  elementt 


Element 

Class 

Restrictions  emd  COTsents 

MPDU 

UserMPDU 

6 

Del i veryRepor tMPDU 

6 

ProbeMPDU 

H 

UserMDPU 

UMPDUEnvelope 

N 

UMPDUContent 

M 

UMPDUEnvelope 

MPDUIdentifier 

N 

originator  ORname 

M 

originalEncodedlnformationTypes  6 

If  this  field  is 

absent,  then  the 

Encoded  Information  Type  is 

"unspecified. " 

Content Type 

M 

UAContentID 

H 

Maximum  length  = 

16  characters. 

Priority 

6 

PerMessageFlag 

6 

Maximum  length  = 

2  octets. 

defer redDeli very 

X 

PerDomainBi laterallnfo 

X 

Mo  limit  on  number  of  occurrences. 

Recipientlnfo 

M 

Maximum  number  = 

32K  -  1  occur r- 

ences.  More  severe  limitations  are 

by  bilateral  agreement. 

Traceinf ormat  ion 

M 

UMPDUContent 

M 

MPDUIdentifier 

GlobalDomainldentif ier 

N 

lASString 

M 

Maximum  length  = 

32  characters. 

graphical  subset 

only.    Refer  to 

T.50  for  clarification  of  graphical 

PerMessageFlag 

subset . 

discloseRecipients 

H 

convers  ionProhibi  ted 

6 

alternateRecipientAllowed 

H 

contentReturnRequest 

X 

I 

I 
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Table  8  -  PI  protocol  elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

PerDomainBi lateral Info 

Count  ryNeune 

M 

Maximum  length  =  3  characters. 

Adm i n i s t r a t i onDoma i nName 

M 

Maximiim  length  =  16  characters. 

BilateralIn£o 

M 

Maximum  depth  =  8;  maximum 

length  =  1024  octets 

(including  encoding). 

Recipient Info 

recipient 

M 

Extensionldentif ier 

M 

Maximum  value  =  32K  -  1  (32767). 

perRecipientFlag 

M 

Maximum  length  =  2  octets. 

Expl i  c  i  t Conve  r  s  i  on 

X 

perRecipientFlag 

ResponsibilityFlag 

M 

ReportRequest 

M 

UserReportRequest 

M 

Tracelnformation 

Reference  should  be  made  to 

Version  5  of  the  X.400  Imple- 

mentor's  Guide  for  information 

GlobalDomainldentif ier 

M 

related  to  Trace  sequencing. 

DomainSuppliedlnfo 

H 

DomainSuppliedlnfo 

arrival 

M 

deferred 

X 

action 

M 

Vj 

l=rerouted  (value) 

H 

Rerouting  is  not  required. 

converted 

H 

previous 

H 

ORName 

See  clause  5.3.5 

EncodedlnformationTypes 

bit  string 

M 

Delivery  can  only  occur  if  match 

is  made  with  Registered  Encoded 

Information  Types.  Individual 

vendors  may  impose  limits. 

Maximum  length  =  4  octets. 

G3NonBasicParameters 

X 

TeletexNonBasicPareuneters 

X 

PresentationCapabilities 

X 
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Table  8  -  PI  protocol  elements  (continued) 


171  Amon^ 

wxnciD 

De 1 i ve r yRepor tMPDU 

Del i veryRepor tEnvelope 

N 

Del i veryRepor tCont ent 

M 

De  1 i  veryRepor  tEnvelope 

report 

N 

originator 

M 

Traceinf ormat ion 

M 

DaI  1  vA  r  vP  otvM' font  fin 

or  iainal 

M 

a 

w 

Saa  ommnAn^          And  c%f  a 

UACon t  ant I D 

Q 

Repor  t edRec  ipi  ent In£o 

M 

Maximum  niunber  =  32K  -  1 
occurrences. 

returned 

H 

Can  only  be  issued  if  specifically 
requested  in  the  originating 

bi llinainf ormat ion 

X 

Maximum  deoth  =  8 :  maximum 
length  =  1024  octets  (including 
encoding) . 

Repor tedRec ipi ent Info 

recipient 

M 

Extensionsldentifier 

M 

PerRecipientFlag 

M 

LastTracelnformation 

M 

i  nt  endedRec  i  p  i  en t 

H 

Supplement arylnformat  ion 

X 

Maximum  length  =  64  characters. 
Value  is  pending  verification  by 
the  CCITT  SG  VIII  or  XI. 

LastTracelnformation 

arrival 

N 

converted 

6 

Report 

M 

I 

) 
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Table  8  -  PI  protocol  elements  (concluded) 


Elenent 

Class 

Restrictions  and 

Comments 

Report 

ueiiverGuiuEo 

t* 

\a 

Generated  if  delivery  is  reported. 

Nondeiiveredinto 

G 

Generated  if  failure  to  deliver 

is  reported. 

DeliveredlnCo 

delivery 

N 

typeotuA 

R 

This  element  must 

be  generated  with 

a  PRIVATE  value  by  PRMDs. 

NonDeliveredlnfo 

ReasonCode 

M 

D i agnos t i cCode 

H 

Whenever  possible 

s,  use  a  meaningful 

diagnostic  code. 

r  r  ooecoi  ve  x  ope 

probe 

M 

originator 

M 

i^oii  b  enc  X  ype 

n 

UAuonc  enc i d 

n 

Maximum  length  = 

16  characters. 

original 

6 

If  this  field  is 

absent,  then  the 

Encoded  Informati 

on  Type  is 

"unspecified. " 

Tracelnformat  ion 

N 

PerMessageFlag 

6 

contentLength 

H 

PerDomainBilaterallnfo 

X 

Recipientlnfo 

M 

Maximum  number  = 

32K  -  1 

occurrences. 

GlobalDomainldentifier 

Count ryName 

M 

Maximum  length  = 

3  characters. 

Admini  St  rat  ionDomainNeune 

(4) 

M 

Maximum  length  = 

16  characters  or 

digits. 

PrivateDomainldentif ier 

R 

Maximum  length  - 

16  characters  or 

digits.    This  element  must  be 

generated  by  PRMDs. 

End 

of  Definitions 

Note:    [Comment  on  intermediate  Tracelnformatlon  in  the  DeliveryReportContent  in  table  8:  Audit  and 
confinned  reports  should  not  be  requested  by  other  than  the  originating  domain  for  two  reasons. 
First,  the  return  path  of  the  report  may  l)e  different  from  the  path  taken  by  the  original  message, 
and  It  may  exclude  the  domain  that  added  the  request  for  audit  and  confirmed  to  the  message. 
Second,  If  the  return  path  is  different  from  the  path  of  the  original  message,  the  originating 
domain  would  receive  intermediate  trace  Information  that  it  did  not  request.] 
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5.3.5      ORName  protocol  elements 

Only  form  1  variant  1  0/R  names  are  supported. 
Table  9  contains  ORName  protocol  elements. 

These  agreements  interpret  1984  X.400  clause  3.4  to  mean  that  the  attributes  in  the  ORName  in  the 
MPDU  must  identify  exactly  one  UA,  and  that  all  the  values  for  the  attributes  specified  in  the  ORName 
must  be  identical  to  the  values  of  the  corresporxilng  attributes  associated  with  the  recipient  UA. 
Underspecified  names  that  are  unique  are  deliverable. 

Overspecified  ORNames,  ORNames  with  mismatching  fields,  and  ambiguous  names  are  to  t>e  non- 
delivered  or  sent  to  the  alternate  recipient  as  appropriate. 
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Tabto  9  -  ORNaoiM  protocol  elements 


Eleneat 

Class 

Restrictions  and  Cooments 

ORNAne 

StandatdAttributeList 

N 

Doiaa  i  nDe  £  i  nedAt  t  c  i  bu  t  eL  i  s  t 

G 

StandardAttcibuteList  (1) 

Count ryNaae 

R 

As  defined  in  X.411,  MaxiauB 

length  =  3  characters. 

AdfliinistratioiiDoaainMaBe  (4) 

R 

Maximun  length  =  16  characters 

or  digits. 

X121Address 

X 

Maximum  length  =  15  digits. 

TeminallD 

X 

Maximum  lenath  =  24  characters . 

PrivateDoBtainNaaie  (2) 

G 

Maximum  length  =  16  characters. 

Organ! zationNaae  (2) 

6 

Maximum  length  =  64  characters. 

UniqueUAIdentifier 

X 

Maximum  length  =  32  digits. 

P6 r 8 ona 1 Nano 

G 

Maximum  lenath  of  values  of  sub— 

elements  =  64  characters. 

Notes    The  oossibilitv  that  this 

value  may  be  reduced  to  40 

characters  is  for  further 

study  by  the  CCITT. 

urganizationaiunit  (3) 

G . 

Maximum  length  =  32  characters  per 

occurrence.    A  maximxun  of  four 

occurrences  are  allowed. 

DomainDefinedAttributeList  (5) 

Maximum  =  4  occurrences. 

type 

N 

Maximum  length  =  8  characters. 

value 

M 

Maximum  length  =  128  characters. 

PecsonalNaae 

surName 

H 

Maximum  length  -  40  characters. 

givenNeune 

6 

Maximum  length  =  16  characters. 

initials 

6 

Maximum  length  -    5  characters; 

excluding  surneune  initial  and 

generationQualifier 

punctuation  and  spaces. 

G 

Maximum  length  =  3  characters. 
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Table  9  -  ORName  protocol  elements  (concluded) 


Motes: 

1  The  following  apply  for  comparison  of  the  Stzmdard  Attributes  of  an 
0/R  Name: 

a)  Lower  case  is  interpreted  as  upper  case  (for  IA5). 

b)  Multiple  spaces  may  be  interpreted  as  a  single  space.  Originating 
domains  shall  only  transmit  single  significeuit  spaces.  If  multiple 
spaces  are  transmitted,  non-delivery  may  occur. 

2  At  least  one  of  these  must  be  supplied. 

3  These  should  be  sent  in  descending  sequence,  from  the  most  significemt 
<Organizational  Unit>  (highest  in  organization  hierarchy)  to  the  least 
significant.  Only  those  specified  should  be  sent.  (That  is,  an 
unspecified  <Organizational    Unit>  should  not  be  sent  along  as  a  field 
of  [null]  content,  nor  zero  length,  etc.) 

4  This  attribute  shall  contain  one  space  in  all  ORNames  of  messages 
originated  in  a  PRMD  that  is  not  connected  to  an  ADMD,  and  in  ORNeunes 
of  recipients  reachable  only  through  a  PRMD;  otherwise,  this  attribute 
shall  contain  an  appropriate  ADMD  neune. 

5  Some  existing  systems  which  will  be  accessed  via  an  X.400  service 
(whether  directly  connected  using  X.400  protocols  or  otherwise)  may 
require  the  provision  of  addressing  attributes  which  are  not  adequately 
supported  by  Standard  Attributes  as  defined  in  these  Agreements.  In 
such  cases,  Domain  Defined  Attributes  are  an  acceptable  means  of 
carrying  additional  addressing  information.  Failure  to  support  the 
specification  and  relaying  of  DDAs  may  prevent  successful  interworking 
with  such  existing  systems  until  such  time  as  all  systems  are  capable 
of  relaying  and  delivery  using  only  the  Standard  Attribute  list. 
Specific  recommendations  on  the  use  of  DDAs  for  particular  applications 
are  in  the  Recommended  Practices,  annex  B. 


5.3.6       P2  protocol  profile  (based  on  p(.420]) 

Tables  10  and  11  classify  the  support  for  the  P2  protocol  elements  required  by  this  profile.  The  tables 
give  restrictions  and  comments  in  addition  to  X.420. 

Restriction  on  length  is  one  of  the  types  of  restrictions.  The  reaction  of  implementations  to  a  violation  of 
this  restriction  is  not  defined  by  this  Profile. 


5.3.6.1         P2  protocol  -  Heading 

Table  10  specifies  the  support  for  protocol  elements  in  P2  Headings. 
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Tabto  10  -  P2  HMdIng  protocol  tlMMntt 


1  EXOMOn^ 

Class 

Rescnccions  ano  woiwicnts 

lUAPDU 

1       In— UAPDU 

Q 

SR-uAPDii 

X 

XN—UAPOU 

N 

1 

Booy 

N 

1 

mm 

N 

1 

originator 

R 

autnOr 1 z inguBdrs 

n 

pr iaaryRecipients 

6 

At  least  one  of  pr iaaryRecipients , 

copyRoc  i  pi  ont  s 

G 

copyRec  i  pi  en t  s ,  or 

blindCopyRecipients  aust  be 

bl indCopyRecipients 

H 

present . 

inReplyTo 

6 

obsoletds 

H 

ccossReferences 

H 

subject 

6 

Kaxiaua  length  «  128  T.61 

characters  (256  octets) ;the  ability 

to  generate  the  aaxiaiui  size 

ezpiryDate 

subject  is  not  required. 

H 

replyBy 

H 

replyToUsers 

H 

ii^rtance 

H 

impropriate  action  is  for  further 

sensitivity 

study. 

a 

impropriate  action  is  for  further 

study. 

autofocwarded 

H 

i 


20 


Part  7: 1984  Message  Handling  Systems  December  1992  (Stable) 


Table  10  -  P2  Heading  protocol  elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

ORName 

H 

PrintableStcing 

N 

Maximum  length  =  64  characters. 

UKuescripbOc 

UKncUBe 

n 

CnA^ 4                       ^DKIamA    u'hAnAwAr    4  4*     4  a 

possioie.    oee  annex  is. 

f  reeCornNaine 

n 

Maximum  length  ~  64  characters. 

graphical  subset  only  (128  octets.) 

n 

Wsv^niiivii    1  An/v^li    =    ^9    ^tifl^s/**^  Ai*a 

nBziinufli  xvuybii  ~  cnacacboLS. 

This  allows  for  punctuation.  It 

aoes  noc  caxe  into  account  possioxe 

Eubuce  use  oy  xslim. 

n 

L^pyJt  uniques  U 

Y 

repiyRec[uest 

IT 

n 

_ 

Body 

MO  xiiDiv  on  nuiDDGr  oi.  ooayirarbS* 

M/N    1  4  m4  4*    /^n    1  An/*t^ ft  H^/lirDx 

no  xiiuiu  on  xen^wn         cmy  ov/aytrcid 

or  cne  aepcn  oc  corwaraeaxrnessage 

Boayrarts  nesvea.  v«xaS8xi.xcabXoii  xs 

subject  to  pending  CCITT  resolution 

SR-UAPDU 

nonReceipt 

H 

receipt 

H 

reported 

M 

actualRecipient 

R 

i n t endedRec i p i ent 

H 

converted 

X 

NonRece i p t I nf or ma t i on 

reason 

N 

nonRece iptQual i £ i er 

H 

comments 

H 

Maximum  length  «  256  characters. 

returned 

H 

May  only  be  issued  if  specifically 

requested  by  originator. 
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Tablo  10  -  P2  Heading  protocol  elements  (concluded) 


Eleaent  Class       Restrictions  and  Comments 


Rece  i  pt Inf orma t  i  on 

receipt  M 
typeOfReceipt  H 

Supplementary Information  X        Maximum  length  =  64  characters. 

Note:  This  value  is  pending 
verification  by  the  CCITT  S6 
VIII  or  IX. 

End  of  Definitions 


5.3.6.2        P2  protocol  -  BodyParts 


5.3.6.2.1  BodyPart  identifiers 

All  BodyParts  with  identifiers  in  the  range  0  up  to  and  including  16K  -1  are  legal  and  should  t>e  relayed. 
BodyPart  identifiers  con-esponding  to  X.I 21  Country  Codes  should  be  interpreted  as  descritied  in  Note  2 
of  figure  4. 

a)  Implementations  are  required  to  generate  and  image  lASText. 

b)  Implementations  should  specify  the  other  BodyPart  types  supported. 

if 

c)  If  an  implementation  supports  a  particular  BodyPart  type  for  reception,  It  should  also  be  able 
to  support  that  BodyPart  type  for  reception  if  it  is  part  of  a  FonvardedlPMessage. 

V. 

'         d)  For  the  BodyPart  types  currently  considered,  support  for  the  protocol  elements  is  as 
a         indicated  in  table  11. 


5.3.6.2.2  Privately  defined  BodyParts 

This  clause  describes  an  interim  means  for  identifying  privately  defined  BodyParts.  This  clause  shall  be 
replaced  In  a  future  version  taking  into  account  CCITT  recommendations  with  equivalent  functionality. 
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BodyPart 


=    CHOICE  { 

[0]  IMPLICIT  lASText, 
[1]  IMPLICIT  TLX, 


234]  IMPLICIT  UKBodyParts, 


310]  IMPLICIT  USABodyParts, 


) 

—  Where  UKBodyParts  and  USABodyParts  are  defined  as: 

SEQUENCE  {  BodyPartNiuDber,  ANY  } 
BodyPartNunber  INTEGER 

Notes 

1  In  the  EncodedlnformationTypes  of  the  PI  Envelope,  the 
undefined  bit  must  be  set  when  a  message  contains  a 
privately  defined  BodyPart.  Each  UA  that  expects  such 
BodyParts  should  include  undefined  in  the  set  of 
deliverable  EncodedlnformationTypes  it  registers  with  the 
MTA. 

2  All  BodyPartNumbers  assigned  must  be  interpreted  relative 
to  the  BodyPart  in  v^ich  they  are  used,  which  is  that 
tagged  with  the  value  [310]  for  those  defined  within  the 
United  States.  The  NIST  assigns  unic[ue  message 
BodyPartNumbers  for  privately  defined  formats  within  the 
United  States. 

3  Refer  to  clause  12.6  for  recommendations  regarding  the 
implementaion  of  USABodyParts. 

Figure  4  -  X.409  definition  of  privately  defined  BodyParts. 


5.3.6.3 


P2  BodyPart  protocol  elements 
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Table  11  -PaBodyParts 


V  V  ^^<Mn         ^  M 

jsxGineurB 

Class 

KeSbriCbions  ana  uomnienvs 

TLX 

Y 

V 
A 

63Fax 

X 

TIFO 

X 

mmv 
1  X  A 

V 
A 

V 
A 

Na  t  i  onal  lyDe  £  i  ned 

X 

Encrypted 

X 

FocwardedlPMessa^e 

99 

n 

oc  u 

V 
A 

1  ir  J. 

V 
A 

un I uen t i t i eu 

V 
A 

lASText 

If 

n 

lASString 

M 

For  rendition  of  lASText  see 

eumex  C. 

TT  V 
lJUA 

For  further  study  by  CCITT. 

Voice 

Set 

For  further  study  by  CCITT, 

BitString 

M 

G3Fax 

numbe  rOfPages 

X 

PI  .G3NonBasicPar2uneters 

X 

SEQUENCE  (OF  BIT  STRING) 

M 

BIT  STRING 

H 

See  Note. 

PI  .GSNonBasicPareuneters 

Support  for  individual  elements  is 

for  further  study. 

TIFO 

T.73Docu]nent 

N 

T. 73ProtocolElement 

H 

See  Note. 
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Tabto  11  •  P2  BodyPaitt  (continued) 


Eleaents 


Class 


Restrictions  and  Ccxnents 


TTX 

nuaberOfPages 

telexCoapat  ible 

PI . TeletexNonBas  icParaas 

SEQUENCE 

T61String 

PI . TeletexNonBas icParaas 
grai^icCharacterSets 
controlCharacterSets 
pageForaats 

ai  scTerainalCapabi 1 i  t  ies 
privateUse 

Videotex 
SET 

VideotexString 

Nat  ional lyDef  ined 
ANY 

Encrypted 

BIT  STRING 

PorwardedlPMessage 
delivery 

Del i veryinf oraat  ion 
IM-UAPDU 

Del i  very Inf oraat  ion 
PI . Content Type 
originator 
original 
PI. Priority 
DeliveryFlags 
otherRecipients 
thisRecipient 
int endedRec  i  pi  ent 
converted 
subaission 


X 
X 
X 
M 
H 


X 
X 
X 
X 
X 


H 
H 
N 


M 
M 
N 
6 
M 
H 
M 
H 
X 
N 


See  Note. 


For  further  study  by  CCITT. 


For  further  study  by  CCITT. 
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Table  1 1  -  P2  BodyParts  (concluded) 


Elements  Class  Restrictions  and  Comments 


SFD 

SFD. Document  M 
TIFl 

T73  Document  M 
T73.ProtocolElement  H  See  note. 


Note:    This  element  is  not  an  addition  to  the  definition  of  the  BodyPart. 
It  is  described  here  to  show  that  the  SEQUENCE  may  contain  zero 
elements.  A  Problem  Report  has  been  submitted  to  the  CCITT  to 
clarify  whether  this  is  permissible.  The  NIST/OSI  Workshop 
will  adopt  the  CCITT  decision. 


5.4      Reliable  Transfer  Server  (RTS) 


5.4.1       Implementation  strategy 

Based  on  X.410  Clause  3  and  X.41 1  Clause  3.5. 


5.4.2       RTS  option  selection 

The  maximum  number  of  simultaneous  associations  Is  not  limited  in  this  profile:  if  the  capacity  of  a 
system  is  exceeded,  it  should  not  initiate  or  accept  additional  associations. 

Associations  are  established  by  the  MTA  which  has  messages  to  transfer. 

Associations  are  released  when  they  are  not  needed.  Associations  may  also  be  ended  prematurely  due 
to  Internal  problems  of  the  RTS. 

For  both  monologue  and  two  way  alternate  associations,  the  initiator  keeps  the  initial  turn. 

When  establishing  an  RTS  association,  the  following  rules  apply  to  the  use  of  parameters  in  addition  to 
those  in  X.410  Clause  3.2.1: 

a)  Dialogue  mode:  Monologue  must  be  supported  for  this  profile;  two-way  alternate  is  used  only 
If  both  partners  agree. 

b)  Initial  turn:  Kept  by  the  initiator  of  the  association. 
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The  "priority-mechanism"  and  the  "transfer-time  limit"  are  regarded  as  local  matters. 
5.4.3       RTS  protocol  options  and  clarifications 

Realization  of  the  RTS  protocol  is  subject  to  the  following  rules  in  addition  to  those  specified  in  X.410 
Clause  4: 

a)  One  RTS  association  corresponds  to  one  or  more  consecutive  session  connections  (not 
concurrent  ones).  The  first  is  opened  with  ConnectionData  of  type  OPEN,  and  subsequent  ones 
are  opened  with  type  RECOVER. 

b)  Recovery  of  a  Session  connection  Is  only  by  RTS  Initiator. 

c)  Checkpoint  size: 

1)  Checl<pointing  and  No  Checkpointing  should  be  supported.  Whenever  possible, 
checl<pointing  should  be  used. 

2)  The  minimum  checkpointSize  is  1  (that  Is.  1024  octets). 

d)  Window  size: 

1)  Minimal  value  of  1  (if  checkpointing  Is  supported). 

2)  WindowSize  =  1  means:  After  an  S-SYNCH-MINOR  request  is  sent,  wait  until  the 
confirmation  is  received  before  issuing  an  S-DATA,  S-SYNCH-MINOR.  or 
S-ACTIVITY-END  request. 

e)  APDUs  should  not  be  blocked  into  one  activity. 

f)  Only  one  SSDU  shall  be  transferred: 

1)  Between  two  adjacent  minor  synch  points. 

2)  Between  minor  synch  points  and  adjacent  S-ACTIVITY-START  and  S-ACTIVITY-END 
requests. 

3)  Between  S-ACTIVITY-START  and  S-ACTIVITY-END  without  checkpoints. 

g)  A  monologue  association  is  defined  as  follows: 

1)  The  RTS  user  responsible  for  establishing  the  association  is  called  the  initiator. 

2)  The  Initiator  keeps  the  initial  turn. 

3)  APDUs  are  transferred  in  the  direction  of  the  Initiator  to  the  recipient  only. 
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4)  There  shall  be  no  token  passing. 

5)  Only  the  Initiator  can  effect  an  orderly  release  of  the  association, 
h)  A  two-way  alternate  association  is  as  described  in  X.410. 

I)  In  the  UserData  parameter  of  the  S-U-ABORT,  the  ReflectedParameter  will  not  be  used  in  the 
Abortlnformation  eiement. 

j)  When  the  S-ACTIVITY-RESUME  is  used  to  resume  an  activity  in  the  same  session  connection 
as  the  one  In  which  It  started,  this  must  happen  Immediately  after  the  activity  has  been 
interrupted  (i.e.,  no  Intervening  activity  can  occur).  Otherwise,  X.410  Qause  4.3  paragraph  1  may 
be  violated. 

k)  When  S-ACTIVITY-RESUME  Is  used  to  resume  an  activity  started  in  another  session 
connection,  the  following  conditions  must  be  met: 

1)  The  current  session  connection  is  of  type  'recover." 

2)  The  value  of  OldSessionConnectionidentifler  in  S-ACTIVITY-RESUME  must  match  the 
value  of  the  SesslonConnectionldentifier  parameter  used  In  the  S-CONNECT  of  the  prior 
session  connection.  This  value  is  also  identical  to  the  SesslonConnectionldentifier  in  the 
ConnectionData  (In  PConnect.  In  SS-UserData)  for  the  current  session  connection. 

3)  This  must  occur  as  the  first  activity  of  the  next  session  connection  for  the  same 
RTS-assoclation.  It  must  be  the  first,  othen/vlse  X.410  Clause  4.5.1  point  1  is  violated. 

NOTE  -  It  is  in  the  same  RTS-ASSOCIATION  t>ecause  the  use  of  S-ACTIVITY-RESUME  only  makes  sense 
within  the  scope  of  one  RTS  association. 

I)  If  the  transfer  of  an  APDU  is  interrupted  before  the  confirmation  of  the  first  checl<point,  the 
value  of  the  SynchronizatlonPointSerialNumber  In  S-ACTIVITY-RESUME  should  be  zero,  and  the 
S-ACTIVITY-RESUME  must  be  immediately  followed  by  an  S-ACTIVITY-DISCARD. 

m)  In  S-TOKEN-PLEASE,  the  UserData  parameter  shall  contain  an  integer  conforming  to  X.409 
which  conveys  the  priority. 

n)  The  receiving  RTS  can  use  the  value  of  the  Reason  parameter  in  the 
S-U-EXCEPTION-REPORT  to  suggest  to  the  sending  RTS  that  it  should  either  interrupt  or 
discard  the  current  activity.  S-U-Exception  Reports  are  handled  as  stated  In  Version  5  of  tfie 
Implementors  Guide  pages  12-13,  paragraph  E-33. 

o)  In  the  case  of  S-P-ABORT,  the  current  activity  (If  any)  is  regarded  as  intemipted,  rather  than 
discarded. 

p)  Tat>le  12  illustrates  the  legal  negotiation  possibilities  allowed  by  X.410  Clause  4.2.1  regarding 
checkpoint  size  and  window  size. 
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q)  These  agreements  include  the  provisions  of  Version  6  of  the  Implementors  Guide  identical  in 
ail  respects  to  Version  5,  except  that  the  following  points  have  been  added  to  clause  3.5: 

1)  for  section  4.4.1  of  X.410;  "if  the  receiving  RTS  receives  an  S-ACTIVITY-DiSCARD 
indication  primitive  and  has  already  Issued  a  TRANSFER  indication  primitive,  it  aborts 
the  connection  (S-U-ABORT  request)  with  the  'transfer  completed'  version  code." 

2)  for  section  4.6.2  of  X.410  The  'transfer  completed  (7)'  abort  reason  is  used  to 
indicate  to  the  sending  RTS  that  the  receiving  RTS  could  not  discard  the  activity 
because  it  has  already  completed  the  transfer  (issued  a  TRANSFER  indication  primitive).' 
Transfer  completed  (7)  is  also  added  to  the  table  of  abort  reasons  in  this  clause. 


Table  12  -  Checkpoint  window  size  of  IP 


acceptor  answer 

CS  =  0 
(or  unspecified) 
WS  unspecified 

CS  =  m 
WS  =  j 
(or  unspecified) 

CS  =  n 
WS  =  j 
(or  unspecified) 

initiator 
proposal 

CS  =  0 
(or  unspecified) 

WS  =  i 
(or  unspecified) 

legal 

legal 

legal 

CS  =  k 
WS  =  i 
(or  unspecified) 

legal 

legal 

not  allowed 

Legend 

CS:    means  Checkpoints ize 
WS:    means  Windows ize 

i,  j,  k,  m,  and  n:    are  integer  values  with  the  following  relations; 
0  ^  m  ^  k  <  n    (values  assigned  to  CS) 
0  <  j  ^  i           (values  assigned  to  WS) 

For  unspecified  parauneters,  the  default  applies.  In  this  case,  the 
numeric  relations  apply,  that  is,  the  default  values  substitutefor 
the  unspecified  integer. 

5.4.4       RTS  protocol  limitations 

The  RTS  Protocol  Limitations  for  this  profile  are  listed  in  table  13. 
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Table  13  -  RTS  protocol  elements 


Element  Class 

Restriction 

PConnect 

M 

DataTrauisferSyntax 

M 

T7s  1 11 A  —  n 

pUserData 

M 

checkpoints! ze 

H 

windows ize 

H 

dialogueMode 

H 

Connect  i  onDat a 

N 

appl i  cat  i  onProtocol 

6 

\f  *  1  11 A     S  1 

H 

\/a1iia    =  Rftfi^ 

Connect  ionData 

open 

6 

recover 

6 

open 

RTS  user  data 

G 

recover 

Sess ionConnect ionldent i f ier 

G 

RTS  user  data 

mTAName 

G 

nT*Anh1^  AiiHflto^           TAR  ^nl  v 

password 

6 

najL X Hiuiu  X cit  o ^  \/w  w  c o 

grapnic  suDseL  or  xas  oniy. 

<  null  RTS  User  Data  > 

G 

Generated  i£  other  validation 

methods  are  used. 

Ses s i onConnec t i onl den t i £ i e r 

Ca 1 1 i  ngSSUs  e r Re  £ e r ence 

M 

Maximiun  length  64  octets  including 

encoding  =62  octets  o£  T.61. 

CommonRe  £e  r  ence 

M 

AdditionalRe£erenceIn£or]nation 

H 

Maximum  length  4  octets  including 

encoding  =  2  octets  o£  T.61. 

PAccept 

G 

Da taTrans£er Syntax 

M 

Value  =  0. 

pUserData 

N 

checkpoints ize 

H 

windows ize 

H 

Connect ionData 

M 
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Table  13  -  RTS  protocol  elements  (concluded) 


Element 

Class 

Restriction 

PRefuse 

RefuseReason 

G 
M 

SS  User  Data 

(in  S-TOKEN-PLEASE) 

G 

See  Note 

Abort Information 
(in  S-U-ABORT) 
Abort Reason 
ref  lectedPareuneter 

G 

H 
X 

Restricted  to 

8  bits. 

End  of  Definitions 

Note  -  Generated  if  supplied  by  the  RTS 
priority  in  the  TURN-PLEASE  primitive, 
SS-User-Data  in  S-TOKEN-PLEASE. 

-user.  The  RTS 
and  if  so,  it 

use  may  specify  a 
is  carried  as  the 

5.5      Use  of  session  services 

The  session  requirements  and  use  of  session  are  covered  in  part  5  of  this  document. 


5.6      Data  transfer  syntax 

This  ciause  defines  Presentation  Transfer  Syntax  and  notation  ruies  applicable  to  these  agreements. 
Implementations  must  conform  EXACTLY  as  specified  in  X.409  with  no  further  restrictions.  Annex  C 
defines  rendition  of  IA5  Text  and  T61  characters. 


6     PRMD  to  ADMD  and  ADMD  to  ADMD 


6.1  Introduction 

This  clause  defines  the  implementation  agreements  that  apply  to  the  interface  between  two  management 
domains  when  at  least  one  is  an  ADMD.  A  message  arriving  at  an  ADMD  has  either  no  recipient  within 
that  domain  or  one  or  more  recipients  within  that  domain.  In  the  former  case,  the  ADMD  serves  as  a 
relay  between  two  or  more  domains  and  the  actions  required  of  that  ADMD  are  independent  of  the 
nature  (PRMD  or  ADMD)  of  the  domains.  In  the  latter  case,  the  ADMD  is  responsible  for  delivering 
messages  to  the  proper  recipient(s)  within  its  jurisdiction,  and  may  also  be  responsible  for  relaying  the 
message. 

Given  the  two  roles  for  an  ADMD,  this  clause  describes  two  distinct  sets  of  functional  requirements  for 
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an  ADMD.  The  first  is  !he  relaying  requirement  that  Is  needed  to  provide  PRMD  and  other  ADMD 
interwort<ing.  The  second  is  analogous  to  the  PRMD's  support  to  its  customers  through  the  integrated 
UAs.  These  are  distinct  functional  differences.  The  services  provided  to  the  UAs  of  an  ADMD  are 
independent  of  the  requirement  that  an  ADMD  provide  a  function  for  intenAfori<ing  with  any  type  of 
Management  Domain  (MD).  Figure  5  liustrates  the  two  roles  played  by  an  ADMD. 

This  clause  is  presented  in  the  form  of  deviations  from  the  agreements  applicable  to  PRMD-to-PRMD 
(sec.  5).  Unless  explicitly  noted  in  the  remainder  of  this  clause,  all  of  the  specifications  for  PRMD  to 
PRMD  apply  to  PRMD  to  ADMD  and  ADMD  to  ADMD. 


(a) 


PRIffl  or  ADMD 


IPM  -  UA 


jaI  <- 

□ 


PI 


-P2- 


(b) 


PRMD  or  ADMD 


-> 


IPM  -  UA 


MTA 


I 
I 
I 
I 
I 
I 

PI 

I 

I 

I 

I 

I 

I 


Figure  5  -  An  ADMD  May  (b)  or  May  Not  (a)  Serve  as  a  Relay. 
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6.2     Additional  ADi\/ID  functionality 

The  following  defines  the  additional  ADMD  specific  functionality  required  over  and  above  that  specified  in 
the  PRMD  clause. 

6.2.1  Relay  responsibilities  of  an  ADMD 

ADMOs  will  relay  all  content  types  (not  just  P2)  unchanged  in  the  absence  of  a  request  for  conversion. 

6.2.2  PI  protocol  classification  changes 

Table  14  describes  the  changes  to  the  PRMD  PI  Protocol  classifications  required  for  a  delivering 
Administration  domain  (with  respect  to  the  original  message;  this  means  the  domain  which  originates  the 
delivery  reports). 


Table  14  -  PI  protocol  classification  changes  for  a  delivering  ADMD 


Protocol  Elements 

Class 

DeliveredIn£o 
typeOfUA 

H 

ReportedRecipientlnfo 
Supplementarylnformation 

H          See  Note  1. 

GlobalDoma i nl dent i £ i e r 
Pr  i vateDomainldent  i  fier 

H 

For  relaying  Administration  domains,  the  classifications  are  all  "X" 

For  originating  Administration  domains,  these  are  all  "NOT  APPLICABLE.** 

Notes 

1    Domains  providing  access  to  TELEX/TELETEX  recipients,  v^ether 
directly  or  indirectly  as  a  result  of  bilateral  agreements 
between  domains,  must  ensure  that  this  information,  when 
present,  is  accessible  by  the  recipient  of  the  delivery  report. 

I  6.2.3       O/R  Names 

I  O/R  Names  shall  consist  of: 

a)  CountryName, 

b)  AdministrationDomainName. 
I  as  well  as  one  or  more  of  the  following: 
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a) 

PrivateDomainName, 

b) 

PersonalName, 

c) 

OrganizationName, 

d) 

OrganizationalUnit, 

e) 

UniqueUAIdentifier, 

f) 

X1 21  Address. 

g)  DomainDefinedAttributeList.  (An  implementation  may  accept  or  reject  an  OR  Name  that  only 
contains  country,  ADMD,  and  DDA  list.) 

NOTE  -  The  destination  PrivateDomainName  or  OrganizationName  must  he  present  if  destined  for  a 
PRMD.  The  ADMD  relaying  the  message  to  that  destination  PRMD  requires  this  element. 

6.2.4  PI  ADMD  name 

Management  Domains  (MDs)  must  specify  in  the  ADMD  name  field  of  the  0/R  Name 
StandardAttributeList  in  P1 ,  the  name  of  the  Administration  domain: 

a)  to  which  the  message  is  being  sent  (in  recipient  names) 

b)  from  which  the  message  originated  (in  the  originator  name). 

6.2.5  Interworking  with  Integrated  UAs 

If  the  message  originates  at  a  UA  owned  by  an  ADMD,  or  is  delivered  to  such  a  UA,  the  0/R  Name 
follows  the  same  Form  1  Variant  1  constraints  as  the  base  specifications;  except  that  the  ADMD  name  is 
the  name  of  the  ADMD  that  owns  the  UA  and  instead  of  supplying  a  PRMD  Name,  one  (or  more)  of  the 
following  must  be  provided: 

a)  OrganizationName, 

b)  OrganizationalUnit, 

c)  PersonalName. 

d)  DomainDefinedAttributeList.  (An  implementation  may  accept  or  reject  an  OR  Name  that  only 
contains  country,  ADMD,  and  DDA  list.) 
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6.3     Differences  with  other  profiles 


6.3.1       TTC  profile 

There  are  no  outstarKling  issues  regarding  interworking  between  TTC-conformant  systems  and 
NIST-conformant  systems  with  the  exception  of  the  numt^er  of  recipients  and  the  supported  MPDU  sizes. 
The  Extensionldentifier  field  may  contain  a  maximum  value  of  32K-1 ;  however,  according  to  the  current 
TTC  profile,  If  a  message  with  more  than  256  recipients  is  received,  some  TTC-conformant  domain  may 
generate  a  nondelivery  notification.  This  also  applies  to  the  ReportedRecipientinfo  in  a  delivery  report. 
Further,  a  TTC  MTA  Is  required  to  handle  an  MPDU  size  of  at  least  32KB.  The  NiST  required  MPDU  size 
Is  2MB  as  covered  In  clause  5.3.3.  Other  differences  are  shown  in  annex  E.  TTC  is  currently  t>ased  on 
Version  4  of  the  Implementor's  Guide. 


6.3.2       CEPT  profile 

See  annex  E. 


6.4     Connection  of  PRMDs  to  multiple  ADMDs 

Given  that  Management  Domain  names  (both  PRMD  and  ADMD)  shall  be  unique  within  the  United 
States,  then  when  an  ADMD  Is  presented  a  message  for  transfer  from  a  PRMD,  it  will  accept  0/R  Names 
(both  originator  and  recipient)  which  have  an  AdministratlonDomainName  field  value  different  than  the 
Administration's  name.  "Accept"  implies  the  attempt  to  route/deliver  the  message  shall  be  made,  as 
appropriate,  based  upon  the  knowledge  that  MD  names  are  unique. 

Whether  this  functionality  Is  required  by  an  Administration  for  conformance  to  this  agreement  is  for 
further  study. 

If  a  PRMD  is  connected  to  two  or  more  ADMDs  which  are  not  effectively  connected  (either  directly  or  via 
a  third  ADMD),  full  X.400  functionality  shall  not  be  available.  Problems  occur  especially  in  the  areas  of: 

a)  Naming. 

b)  Routing. 

c)  Replying. 

It  should  be  noted  that  a  single  PRMD  that  Is  connected  to  more  than  one  ADMD  can  be  represented  by 
more  than  one  combination  of  country-name.  ADMD-name.  and  PRMD  name.  For  example.  It  may  occur 
that  the  PRMD-name  for  a  particular  PRMD  may  take  different  values,  depending  on  the  ADMD-name. 
Implementors  should  be  aware  of  the  consequences  of  these  possibilities  on  routing. 
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6.5 


Connection  of  an  ADMD  to  a  routing  PRMD 


It  is  possible  for  a  collection  of  interconnected  private  domains  to  establish  one  domain  as  the  "gateway" 
to  an  ADMD,  and  hence  to  the  world. 

If  an  ADMD  Is  connected  to  such  a  gateway  PRMD,  the  individual  private  domains  shall  be  registered 
with  the  Administration.  Administrations  need  not  support  such  connections. 

Note  also  that  upon  receipt  by  the  ADMD  of  a  message  originating  somewhere  within  the  PRMD 
collection,  that  the  Tracelnformation  may  contain  more  than  one  element. 

The  X.400  Recommendations  specify  that  an  ADMD  should  not  attempt  to  relay  a  message  destined  for 
another  ADMD  through  a  PRMD,  thus  an  ADMD  should  ensure  that  messages  destined  for  another 
ADMD  are  not  relayed  through  a  PRMD.  It  should  be  noted,  however,  that  a  relaying  PRMD  will  relay  any 
such  message  it  receives. 


6.6      Management  domain  names 

All  Management  Domain  Names  (both  Private  and  Administration)  shall  be  unique  within  the  U.S. 
A  central  naming  authority  shall  be  established  to  register  domain  names. 


6.7      Envelope  validation  errors 

For  validation  errors,  a  non-delivery  notice  shall  be  generated  (if  possible)  with  reason  code  of 
"unaWeToTransfer"  and  diagnostic  code  of  "invalidParameters"  (unless  specified  otherwise). 

ADMDs  will  validate  P1  Envelopes  in  the  following  areas: 

a)  The  X.409  syntax  of  all  elements  should  be  checked. 

b)  The  pragmatic  constraint  limits  (lengths  of  fields  and  number  of  occurrences  of  fields)  should 
be  checked. 

c)  Semantic  validation  of  the  following  elements  should  be  done: 

1)  originator  0/R  Name, 

2)  recipient  0/R  Name  in  the  Recipientlnfo, 

3)  Priority. 

d)  Only  recipient  Names  with  the  responsibility  flag  set  should  be  validated.  The  validation  of 
0/R  names  is  defined  in  8.3.3;  the  validation  of  priority  is  defined  in  8.3.7.1. 
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e)  MPDU  Identifier  Validation 

1)  Validation  of  the  Glot)alDonfiainidentlfier  component  of  the  MPDU  Identifier  is 
performed  upon  reception  of  a  message  (i.e..  as  a  result  of  a  TRANSFER.Indication). 

2)  The  country  name  should  be  known  to  the  validating  domain,  and  depending  on  the 
country  name,  validatton  of  the  ADMD  name  may  also  t>e  possit>ie. 

3)  Additional  validation  of  the  GlobalDomainldentifier  is  performed  against  the 
corresponding  first  entry  in  the  Tracelnformation.  If  inconsistencies  are  found  during  the 
comparison,  a  non-delivery  notice  with  the  above  defined  reason  and  diagnostic  codes 
is  generated. 

4)  A  request  will  be  generated  to  the  CCITT  for  a  more  meaningful  diagnostic  code 
(such  as  "InconsistentMPDUIdentifier"). 


6.8     Quality  of  service 


6.8.1       Domain  availability 


6.8.1 .1        ADMD  availability 

The  goal  is  to  provide  24  hour  per  day  availability.  Note  that  there  will  be  periods  of  time  when  an  ADMD 
may  be  unavailable  due  to  maintenance  windows  in  its  supporting  network  or  in  an  MTA  within  the 
domain. 


6.8.1 .2        PRMD  availability 

Although  the  goal  of  PRMD  availability  is  also  24  hours  per  day,  business  reasons  are  likely  to  dtotate 
some  different  level  of  availability.  ADMDs  shall  require  a  profile  from  the  PRMD  that  indicates  Its 
schedule  of  regular  availability  to  the  ADMD. 


6.8.2       Delivery  times 

In  the  absence  of  standardized  quality  of  service  parameters,  the  following  are  agreed  to.  When 
standardized  parameters  from  (XITT  Study  Group  I  become  available,  they  shall  be  adopted. 

a)  In  table  15  the  delivery  time  targets  are  established. 

b)  The  interval(s)  between  retries  and  the  number  of  retry  attempts  that  an  ADMD  uses  in 
attempting  delivery  to  a  PRMD  or  integrated  UA.  will  be  locally  detennined  domain  parameters. 
However,  the  total  elapsed  times  after  which  delivery  attempts  will  be  stopped  are  shown  in  table 
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16.  This  implies  that,  after  these  times,  a  Non-Delivery  Notice  will  be  generated. 

c)  An  Administration  shall  continue  to  attempt  delivery  until  the  forced  nondelivery  time,  even  if 
the  recipient  domain  has  scheduled  an  unavailability  window. 


Table  15  -  Delivery  time  targets 


Delivery  Class 

95%  Delivered  Before 

Urgent 
Normal 
Non-Urgent 

3/4  hour 
4  hours 
24  hours 

Table  16  -  Forced  nondelivery  times 


Delivery  Class 

NonDelivery  Forced  After 

Urgent 
Normal 
Non-Urgent 

4  hours 
24  hours 
36  hours 

NOTE  -  Both  tables  apply  to  the  period  between  acceptance  by  the  originating  MTA  in  the  originating 
Administration  domain  to  the  time  of  delivery  in  the  destination  Administration  domain.  Transit  time  within 
PRMDs  is  NOT  included  in  the  above  times. 


6.9      Billing  information 

All  aspects  relating  to  billing,  charging,  tariffs,  settlement,  and  in  particular  to  the  use  of  the 
billinglnformation  field  in  the  delivery  report,  is  subject  to  bilateral  agreement,  and  shall  not  be  addressed 
in  these  implementation  agreements. 

No  ADMD  shall  require  a  PRMD  to  supply  or  process  billing  information. 


6.10  Transparency 

No  PI  extensions,  other  than  the  MOTIS  extensions  are  to  be  allowed  (Reference  A/3211).  Should  an 
ADMD  receive  a  message  containing  Pi  extensions,  it  shall  generate  a  non-delivery  notice  (if  possible) 
with  reason  code  of  unalDleToTransfer  and  diagnostic  code  of  invalidParameters. 

If  MOTIS  elements  are  present,  a  relaying  MTA  can  optionally: 

a)  Relay  the  message.  If  the  MTA  does  relay,  it  must  not  drop  any  of  the  protocol  elements. 

b)  Non-Deliver  the  message. 
A  receiving  MTA  can  optionally: 
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a)  Deliver  the  message 

b)  Non-Deliver  the  message. 

The  CCITT  has  been  requested  to  establish  a  more  meaningful  diagnostic  code  (such  as  protocolEn^or) 
for  this  occurrence.  Such  a  code  has  now  been  provided  in  the  Implementors  Guide. 

P2  extenstons  shall  be  relayed  transparently  by  AOMDs. 


6.1 1    RTS  password  management 

RTS  password  management  shall  be  a  local  matter.  This  includes: 

a)  password  length 

b)  frequency  of  changes 

c)  exchange  of  passwords  with  communicating  partners 

d)  loading  passwords  ( i.e.,  the  timing  of  password  changes  with  respect  to  active 
associations). 


ii  6.12    For  further  study 

i 

Issues  requiring  further  study  are: 

a)  Intra-Domain  Routing 

b)  Multi-Vendor  Domains 


7    Inter  and  intra  PRMD  connections 


7.1  Introduction 

This  clause  is  limited  in  scope  to  issues  arising  from  the  indirect  connection  of  a  PRMD  to  another 
PRMD  or  to  an  ADMD,  and  to  the  interconnection  of  MTAs  to  form  inter-PRMD  connections.  Indirect 
means  that  the  connection  is  made  via  a  relaying  PRMD.  The  X.400  Recommendations  descrit)e  the  way 
that  a  PRMD  connects  to  a  ADMD  and  the  way  that  an  ADMD  connects  to  another  ADMD.  The 
Recommendations  do  not,  however,  describe  the  way  that  a  PRMD  connects  indirectly  to  an  ADMD  or 
I  another  PRMD,  nor  do  they  describe  the  way  that  MTAs  are  connected  within  a  PRMD.  These 
(  configurations  (shown  in  figures  6  and  7)  are  useful,  for  example,  in  connecting  equipment  from  different 
\  vendors  at  a  single  customer  site. 
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The  P1  protocol  and  its  related  services  for  both  inter  and  Intra  PRMD  connections  are  addressed  In  this 
clause,  in  addition,  a  method  for  routing  within  a  PRMD  is  given.  It  is  recognized  that  uniform  methods 
for  Administration,  maintenance,  and  quality  of  service  should  be  developed  for  such  configurations,  and 
this  work  is  for  further  study. 

This  clause  describes  the  minimum  that  must  be  provided  in  order  to  implement  a  relaying  PRMD  and  a 
MTA  within  a  PRMD. 

This  clause  is  presented  in  the  fomi  of  deviations  from  agreements  applicable  to  PRMD  to  PRMD 
connection  (sec.  5).  That  is,  unless  specifically  noted  in  the  remainder  of  this  clause,  the  agreements  In 
clause  5  apply  to  both  relaying  PRMDs  and  MTAs  within  a  PRMD. 

It  should  be  noted  that  the  comments  regarding  ORNames  in  clause  6.5  also  apply  to  this  clause. 


7.2      The  relaying  PRMD 

A  PRMD  that  has  the  capability  of  relaying  messages  to  another  PRMD  is  called  a  relaying  PRMD.  A 
PRMD  implementation  need  not  claim  to  be  a  relaying  PRMD.  A  PRMD  implementation  which  does  dalm 
to  be  a  relaying  PRMD  must  follow  the  implementation  agreements  in  this  clause. 


7.2.1       Relay  responsibilities  of  a  PRMD 

The  responsibilities  of  a  relaying  PRMD  are  the  same  as  those  of  an  ADMD  (as  specified  in  sees.  6.8  and 
6.2.1).  In  addition,  the  PRMD  will  simply  deliver  messages  routed  to  it  from  an  ADMD,  even  if  this  results 
in  routing  a  message  from  the  ADMD  to  the  PRMD  to  another  ADMD. 


7.2.2       Interaction  with  an  ADMD 

in  order  for  an  ADMD  to  route  a  message  to  ADMD  A  via  ADMD  B,  it  must  l<now  that  A  is  reachable 
through  B.  Similarly,  in  order  for  any  MD  to  route  a  message  to  PRMD  A  via  a  relaying  PRMD  B,  It  must 
know  that  A  is  reachable  through  B  (see  figure  8). 


ADMD 


I 


PRMD  A 

PRMD  B 

PRMD  C 

Relay 


Figure  6  -  Relaying  PRMD. 
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PRMD 


MTA  A 


MTA  D 


MTA  B 


MTA  C 


ADMD 

or 
PRMD 


Figure  7  -  Intra  PRMD  connections. 


NOTES 


1  Clause  6.6  specifies  that  ADMDs  are  not  required  to  connect  to  a  relaying  PRMD,  but  they  are  not 
precluded  from  doing  so. 

2  Tracelnfbrmation  may  have  more  than  one  sequence  on  submission  of  a  message  by  a  relaying  PRMD 
to  an  ADMD. 


MD  D 


relay 

MD    C  with 
a  message 
for  A 

relay 
MD  B 

MD  A 

Figure  8  -  MD  C  must  Icnow  of  A  to  route  tlie  message. 

7.3      Intra  PRMD  connections 

A  PRMD  is  composed  of  MTAs  which  cooF>erate  to  perform  the  functions  expected  of  a  domain.  An  MTA 
implementation  need  not  claim  to  follow  the  implementation  agreements  of  this  clause. 
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7.3.1       Relay  responsibilities  of  an  MTA 

The  relaying  responsibilities  of  an  MTA  are  the  same  as  those  of  an  ADMD  (as  specified  in  6.8  and  6.2.1) 
with  one  exception:  loop  suppression  within  the  domain  Is  done  using  the  MOTIS  IntemalTracetnfo 
protocol  element.  The  MTA  must  validate  the  intemalTraceinfo  (see  8.3.5  for  details  on  validation).  In 
addition,  the  PRMD  will  simply  deliver  messages  routed  to  It  from  an  ADMD,  even  if  this  results  in  routing 
a  message  from  the  ADMD  to  the  PRMD  to  another  ADMD  (please  see  6.6). 


7.3.2       Loop  suppression  within  a  PRMD 

The  only  mechanism  defined  in  the  X.400  RecommerxJations  for  suppressing  loops  is  Tracelnformation, 
which  is  added  on  a  per  domain  basis  to  detect  and  suppress  loops  among  domains.  Loops  among 
MTAs  within  a  domain  need  to  be  detected  and  suppressed.  This  implies  that  each  MTA  must  add  trace 
infomnation  that  is  meaningful  within  the  domain.  The  MOTIS  solution  of  adding  IntemalTraceinfo  to  the 
PI  Envelope  of  a  message  was  adopted.  The  definition  of  IntemalTraceinfo  is  given  in  figure  9.  The 
IntemalTraceinfo  is  added  by  each  MTA  within  a  PRMD  to  handle  a  message,  and  it  is  examined  in  the 
same  way  as  Tracelnformation  to  detect  and  suppress  loops. 


IntemalTraceinfo 

::=  [APPLICATION  30]  IMPLICIT  SEQUENCE  OF  SEQUENCE  ( 
MTAName, 

MTASuppliedlnfo  } 

MTANaune 

::=  PrintableString 

Figure  9  -  Definition  of  InternalTraoelnfo. 


if  the  MTAName  and  password  of  X.41 1  are  used  for  validation,  then  it  is  recommended  that  the 
MTAName  used  for  validation  also  be  used  in  the  IntemalTraceinfo.  However,  there  is  a  complication:  in 
X.411,  MTAName  is  an  lASString,  and  the  MTAname  defined  by  MOTIS  is  a  PrintableString.  Efforts  will  be 
made  to  change  the  MOTIS  definition  from  PrintableString  to  lASString. 

Three  actions  are  defined  in  MTASuppliedlnfo:  relayed,  rerouted,  and  recipientReassignment  as  shown  in 
figure  10.  The  recipientReassignment  action  Is  not  supported  in  these  agreements.  The  ability  to 
generate  it  is  not  required,  and  if  it  is  present  on  an  incoming  message,  the  action  field  will  be  ignored. 


MTASuppl i  edinfo 

::=  SET  { 

arrival 

[0]  IMPLICIT  Time, 

deferred 

[1]  IMPLICIT  Time  OPTIONAL, 

action 

[2]   IMPLICIT  INTEGER  { 

relayed 

(0), 

rerouted 

previous 

recipientReassignment 

(2)  } 

MTAName  OPTIONAL  } 

Figure  10  -  Defined  actions  in  MTASuppliedlnfo. 
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7.3.3       Routing  within  a  PRMD 

Routing  within  a  PRMD  is  complicated  by  the  lack  of  a  directory  standard.  In  particular,  it  constrains 
Intra-domain  routing  decisions  to  be  based  on  some  combination  of  the  intra-domain  attributes  of  the 
0/R  Name,  Organization  Name  Organizational  Units,  and  Personal  Name,  in  order  to  enhance 
interworking  and  to  reduce  the  difficulty  of  configuring  Intra-domain  connections,  it  is  useful  to  restrict 
the  ways  In  which  these  may  be  used  in  making  routing  decisions. 

However,  it  Is  recognized  that  vendors  may  wish  to  provide  MTAs  with  varying  degrees  of  routing 
capability  within  a  PRMD  as  a  temporary  expedient  until  appropriate  standards  for  automated 
construction  of  directories  and  routing  tables  are  available.  This  clause  assigns  class  numbers  to  certain 
levels  of  routing  capability  and  discusses  the  consequences  of  using  MTAs  which  fall  into  each  class. 
The  classification  scheme  will  allow  some  diversity  in  allocating  0/R  Name  space  and  in  configuring 
intra-domain  routes. 

When  other  methods  are  recommended  by  standards  bodies,  the  classification  scheme  described  here 
will  become  obsolete.  Large-scale,  multi-vendor  PRMDs  may  not  be  practical  in  the  absence  of 
standardized  methods. 


7.3.3.1        Class  designations 

When  it  is  clear  that  a  message  is  to  be  delivered  within  a  domain,  the  Country  Name,  ADMD  Name,  and 
PRMD  Name  have  already  served  their  purpose  in  determining  the  next  MTA  in  the  route  to  the  recipient. 
The  remaining  fields  that  might  be  used  on  making  routing  decisions  within  the  PRMD  are  the 
Organization  Name,  Organizational  Units,  and  Personal  Name. 

MTAs  are  classified  by  their  ability  to  discriminate  between  0/R  names  when  making  routing  decisions 
within  a  PRMD.  Conformant  MTAs  will  be  classified  as  shown  in  table  1 7. 


Table  17  -  Conformant  MTA  classifications 


Class  1 

Class  2 

Class  3 

Organization  Neune 

H 

H 

H 

SEQUENCE  OF  Organizational  Unit 

X 

H 

H 

Personal  Neune 

X 

X 

H 

An  "H"  means  that  the  MTA  must  be  able  to  tjase  its  intra-domain  routing  decisions  on  the  given 
component  of  the  0/R  Name.  In  particular,  both  Class  2  and  Class  3  MTAs  must  be  able  to  discriminate 
on  all  the  members  in  a  supplied  sequence  of  OrganizationalUnits.  A  Class  3  MTA  must  be  able  to 
discriminate  on  all  of  the  elements  in  a  PersonalName. 

An  "X"  means  that  the  MTA  need  not  have  the  ability  to  discriminate  on  the  given  component. 

There  is  a  hierarchy  In  support  of  components.  The  ability  to  discriminate  on  a  given  component  does 
not  Imply  the  requirement  to  do  so:  e.g.,  a  Class  3  MTA  is  not  required  to  have  tables  for  every 
PersonalName  in  the  domain.  Equally,  an  MTA  which  can  discriminate  on  OrganizationalUnits  to  make 
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routing  decisions  need  not  always  use  the  full  sequence  In  an  0/R  Name  if  a  partial  sequence  provides 
enough  infonnation. 

The  atxive  classifications  only  apply  to  routing  decisions  In  selecting  a  next  hop  within  a  domain.  AN 
MTAs  are  entitled  to  examine  the  full  0/R  Name  when  Identifying  their  own  directly  served  UAs. 

The  routing  table  of  a  Class  1  MTA  wHI  be  relatively  small,  because  intra-domain  routing  decisions  are 
based  solely  on  OrganizationName.  The  routing  table  of  a  Class  2  MTA  may  be  substantially  larger  and 
more  complex  because  of  its  ability  to  discriminate  on  OrganizationatUnits  as  well  as  OrganizationName 
to  make  routing  decisions.  The  routing  table  of  a  Class  3  MTA  may  be  larger  stHI.  because  its  use  of  the 
components  of  PersonalName  in  addition  to  the  other  information. 


7.3.3.2        Specification  of  MTA  classes 

If  an  MTA  implementation  claims  to  follow  the  implementation  agreements,  it  must  be  either  a  Class  1, 
Class  2,  or  a  Class  3  MTA.  The  dass  of  an  MTA  implementation  should  be  specified  so  that  PRMD 
administrators  can  choose  equipment  property. 


7.3.3.3        Consequences  of  using  certain  classes  of  MTAs 

Definition:  An  MTA  which  accepts  submission  requests  and  fumishes  delivery  indications  to  a  UA  is  said 
to  "directly  serve"  the  UA. 

The  presence  in  a  domain  of  an  MTA  acting  as  a  Class  1  or  Class  2  MTA  imposes  administrative 
restrictions  on  the  assignment  of  0/R  Names  to  UAs  and  in  the  configuration  of  routes  within  that 
domain. 

A  Class  1  MTA  may  directly  serve  UAs  from  several  OrganizationNames.  IHowever,  if  a  Class  1  MTA 
directly  serves  a  UA  with  a  given  OrganizationName.  no  other  MTA  in  the  domain  may  directly  serve  a 
user  with  the  same  OrganizationName.  This  means  that  if  all  MTAs  in  a  domain  are  Class  1,  then  all  UAs 
with  a  given  OrganizationName  must  be  assigned  to  the  same  MTA. 

A  Class  2  MTA  may  directly  serve  UAs  from  any  combination  of  OrganizationName  and  sequence  of 
OrganizatlonalUnits.  However,  if  a  Qass  2  MTA  directly  serves  a  UA  with  a  given  combination,  no  other 
MTA  in  the  domain  may  directly  serve  a  user  with  the  same  combination.  This  means  that  If  all  MTAs  In  a 
domain  are  Class  2.  then  ail  UAs  with  a  given  OrganizationName  and  sequence  of  OrganizatlonalUnits 
must  be  assigned  to  the  same  MTA. 

A  domain  consisting  entirely  of  Qass  3  MTAs  is  free  of  ail  the  above  restrictions. 

if  Class  1  or  Qass  2  MTAs  are  used  to  perform  relaying  within  a  PRMD  containing  MTAs  of  other 
classes,  care  must  be  exercised  in  determining  the  topology  of  the  domain  to  avoid  leaving  certain  UAs 
inacessible  from  certain  MTAs  within  the  domain.  The  example  below  shows  one  of  the  configurations 
that  should  be  avoided.  The  example  is  intended  to  stimulate  careful  examination  of  the  relationship 
between  network  and  organizational  topologies. 
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MTA  A 
serving 
Orgsuiization  X 


MTA  B 
(Class  1) 


MTA  C 
serving 
Organization  X 


Figure  1 1  -  Example  of  a  configuration  to  be  avoided. 


In  figure  1 1,  B  will  route  all  messages  for  Organization  X  to  either  A  or  C  because  B  is  a  Gass  1  MTA. 
The  administrator  who  created  this  configuration  probably  wanted  B  to  route  some  messages  for 
Organization  X  to  A,  and  some  to  0.  However,  B  does  not  have  the  capability  for  this  because  it  is  only 
a  Class  1  MTA.  The  configuration  in  figure  1 1  can  be  corrected  by  replacing  B  with  a  Class  2  or  Class  3 
MTA. 


7.3.4       Uniqueness  of  MPDUidentifiers  within  a  PRMD 

When  generating  an  lASString  in  an  MPDUIdentifier,  each  MTA  In  a  domain  must  ensure  that  the  string  is 
unique  within  the  domain.  This  shall  be  done  by  providing  an  MTA  designator  with  a  length  of  12  octets 
which  is  unique  within  the  domain,  to  be  concatenated  to  a  per  message  string  with  maximum  length  of 
20  octets. 


Two  pieces  of  information,  the  MTA  name  and  MTA  designator,  need  to  be  registered  within  a  PRMD  to 
guarantee  uniqueness.  This  registration  facility  need  not  be  automated.  If  the  MTA  name  is  less  than  or 
equal  to  12  characters,  it  is  recommended  that  it  also  be  used  as  the  MTA  designator. 


ij  7.4     Service  elements  and  optional  user  facilities 

A  PRMD  made  up  of  MTAs  which  support  varying  sets  of  service  elements  in  addition  to  those  required 
in  these  agreements  may  appear  to  provide  inconsistent  service  for  these  elements.  For  example,  if  one 
MTA  supports  deferred  delivery  and  another  MTA  does  not,  then  deferred  delivery  can  be  used  by  some, 
but  not  all,  users  in  the  PRMD.  Similarly,  if  one  MTA  supports  return  of  contents  and  another  does  not, 

I  then  a  user  outside  of  the  PRMD  will  receive  returned  contents  for  messages  sent  to  one  user,  but  not 
for  messages  sent  to  another  user.  Note  that  this  same  inconsistency  occurs  when  sending  to  two 

I  PRMDs  which  support  different  additional  optional  elements. 
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7.5     X.400  protocol  definitions 

This  dause  describes  additions  and  modifications  to  clause  5.3  wliich  are  required  for  implementation  of 
a  relaying  PRMO  or  an  MTA  within  a  PRMD. 


7.5.1       Protocol  classification 

The  classification  scheme  given  in  clause  5.3.1  applies  to  elements  passing  from  one  PRMD  to  another. 
For  tx>th  relaying  PRMDs.  and  MTAs  in  a  PRMD,  the  same  classification  scheme  will  be  used,  but  within 
a  PRMD  the  classification  applies  to  elements  passing  from  one  MTA  to  anotlier. 

In  addition  to  the  classifications  given  in  clause  5.3.1,  a  classification  of  Prohit}ited  has  been  used. 
PROHIBITED  =  P 

This  element  shall  not  be  used.  Presence  of  this  element  is  a  protocol  violation. 


7.5.2       PI  protocol  elements 

Table  18  contains  protocol  elements  and  their  classes.  An  *  signifies  that  the  classification  of  the 
protocol  element  has  not  changed  from  table  8. 
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TabI*  18  -  PI  protocol  •iamontt 


Eleaent 

Class 

Restrictions  and  Comments 

UMPDUEnvelope 
MPDCJIdentifier 

M* 

This  field  needs  to  be  unique 
within  a  PRMD.    See  clause 
7.3.4  for  the  method  of 
ensuring  uniqueness. 

originator 

M* 

It  is  recommended  that  all 
components  of  the  originator's 
ORName  be  included  to  help  ensure 
that  reports  can  be  returned. 

TraceIn£ormat  ion 

M* 

The  first  MTA  in  the  domain  to 
receive  the  message  adds  the 
Tracelnformation.  Subsequent 
MTAs  can  update  the 
Tracelnformation  in  the  event  of 
conversion  or  deferred  delivery. 
When  a  message  is  generated,  the 
originating  MTA  adds  the 
Traceinf ormat  ion . 

InternalTracelnfo 

M/P 

This  element  is  m2mdatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
Elements  are  always  added  to  the 
end  of  the  sequence.  (See  Note  1) 

InternalTracelnfo 
MTANaae 

M 

MTANames  within  a  PRMD  must  be 
unique.  See  clause  7.3.4  for 
the  method  of  assuring  uniqueness 
Maximum  length  =  32  characters. 

MTASuppl i edinfo 

M 
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Table  18  -  PI  protocol  elements  (continued) 


1  

Element 

Class 

Restrictions  and  Comments 

MTASuppl i  edinf o 
arrival 
deferred 

M 
X 

This  field  must  be  generated  by 
MTAs  which  perform  deferred 
delivery. 

action 

M 

See  clause  7.3.2  for 
restrictions  on  values  of  this 
field. 

previous 

X 

This  field  must  be  generated  by 
MTAs  which  perform  rerouting. 

DeliveryReportEnvelope 
Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  report  adds  the 
Tracelnformation.  When  a  report 
is  generated,  the  originating  MTA 
adds  the  Tracelnformation. 

InternalTraceIn£o 

DeliveryReportContent 

intermediate  InternalTraceIn£o 

M/P 
P 

This  field  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
(See  Note  1) 

If  it  were  possible  to  include 
this  field  in  the  delivery  report 
content,  an  audit  and  confirmed 
report  could  be  provided  to 
detect  problems  within  a  PRMD. 
Efforts  are  being  made  to  add 
this  field  to  the  MOTIS 
definition. 

Deliveredlnfo 
typeOFUA 

R* 

It  is  the  responsibility  of  the 
MTA  generating  the  report  to 
generate  this  element. 
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Table  18  -  PI  protocol  etoments  (concluded) 


Elenent 


Class 


Restrictions  and  Coaments 


ProbeEnvelope 
TraceIn£ocmat ion 


InternalTracelnfo 


M*  The  first  MTA  in  the  d(»ain  to 

receive  the  probe  adds  the 
Tracelnformation.  When  a  probe 
is  generated,  the  originating  MTA 
adds  the  Tracelnforaation. 

H/P        This  field  is  a2uidatory  for 

envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  d<»ain. 
(See  Note  1) 


itotes 

1    The  M  classification  is  only  applicable  if  an  implenentation  is 
claiaing  conformance  according  to  clause  10.2. 


7.5.3      Reliable  Transfer  Server  (RTS) 

In  the  pUserData  of  PConnect,  the  value  of  appllcationProtocol  should  be  1.  This  value  was  chosen 
because  the  agreements  on  intra-domain  connections  are  not  strictly  PI,  rK>r  are  they  MOTIS. 
Phlosophlcally,  It  would  be  good  to  choose  a  new  application  protocol  identifier  for  these  agreements, 
but  this  introduces  too  many  practical  problems.  Since  these  agreements  are  closer  to  PI  tlian  to 
MOTIS.  the  value  of  1  will  be  used.  This  will  not  cause  intenvorking  problems  between  domains,  because 
the  only  deviation  from  PI  is  the  IntemaiTracelnfo,  which  wUI  not  be  present  in  messages  transfen^ed 
outside  of  a  domain. 


8    Error  handling 

This  clause  describes  appropriate  actions  to  be  taken  upon  receipt  of  protocol  elements  whk;h  are  not 
supported  in  this  profile,  malfomned  MPDUs.  unrecognized  0/R  Name  fonns.  content  en'ors.  errors  In 
/i  reports,  and  unexpected  values  for  protocol  elements. 
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8.1      MPDU  encoding 

The  MPDU  should  have  a  context-specific  tag  of  0,  1,  or  2.  If  it  does  not  have  one  of  these  tags,  it  Is  not 
possible  to  figure  out  who  originated  the  message.  Therefore,  the  way  this  error  is  reported  is  a  local 
matter. 


8.2  Contents 

Once  delivery  to  the  UA  has  occurred,  it  is  not  possible  to  report  errors  in  P2  information  to  the 
originator.  In  addition,  it  seems  unreasonable  to  insist  that  the  MTA  that  delivers  a  message  ensure  that 
the  P2  content  of  the  message  is  acceptable.  As  a  result,  the  handling  of  content  errors  Is  a  local  matter. 


8.3  Envelope 

This  clause  describes  the  handling  of  errors  in  message  envelopes.  Some  of  the  error  conditions 
described  below  may  be  detected  in  a  recipient's  0/R  Name.  This  may  limit  the  reporting  MTA's  ability 
to  generate  a  nondelivery  notification  that  accurately  reflects  the  erroneous  0/R  Name  in  the 
ReportedRecipientlnfo.  This  handling  of  this  situation  is  a  local  matter. 


8.3.1       Pragmatic  constraint  violations 

In  all  cases  of  pragmatic  constraint  violation,  a  nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  pragmaticConstraintViolation. 


8.3.2       Protocol  violations 

If  all  required  protocol  elements  are  not  present,  a  nondelivery  report  with  a  ReasonCode  of 
unat)leToTransfer  and  a  DiagnosticCode  of  protocolViolation  should  be  generated. 

If  a  protocol  element  is  expected  to  be  of  one  type,  but  is  encoded  as  another,  then  a  nondelivery  report 
with  a  ReasonCode  of  unableToTransfer  and  a  DiagnosticCode  of  invalidParameters  should  be 
generated. 


8.3.3       O/R  Names 

The  domain  that  has  responsibility  for  delivering  a  message  should  also  have  the  responsibility  to  send 
the  nondelivery  notification  if  the  message  cannot  be  delivered.  Therefore,  each  MTA  should  only 
validate  the  0/R  Names  of  recipients  with  responsibility  flags  set  to  TRUE.  In  addition,  a  nondelivery 
notification  can  only  be  sent  if  the  originator's  0/R  Name  is  valid. 

If  any  element  in  the  0/R  Name  is  unrecognized  or  if  the  CountryName,  AdministrationDomalnName, 
and  one  of  PrivateDomainName  and  OrganizationName  (and,  for  ADMDs,  PersonalName  and 
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OrganizationalUntt)  are  not  all  present,  then  a  nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unat)leToTransfer.  and  a  DiagnosticCode  of  unrecognizedORNanie.  If  the  message  can 
be  delivered  even  though  the  ORName  is  invalid,  delivery  is  a  local  matter.  Note,  however,  that  if  the 
message  is  delivered,  the  invalid  ORName  might  be  propagated  through  the  X.400  system  (e.g..  by 
forwarding). 

If  the  0/R  Name  has  all  of  the  appropriate  protocol  elements  and  the  message  still  cannot  be  delivered 
to  the  recipient,  the  following  DiagnosticCodes  may  appear  in  the  nondelivery  report: 
unrecognizedORName,ambiguousORName,and  uaUnavailable. 


8.3.4  Tracelnformatlon 

Since  non-relaying  domains  need  not  do  loop  suppression,  domains  with  responsibility  for  delivering  the 
message  need  not  be  concemed  about  the  semantics  of  the  Tracelnformatlon,  that  is,  arrival  time  and 
converted  EncodedlnformationTypes  can  be  provided  to  the  UA  without  Inspection  by  the  MTAs  of  the 
domain  as  long  as  the  Tracelnformatlon  is  properly  encoded  according  to  X.409. 

When  a  message  is  accepted  for  relay,  the  relaying  domain  must  check  that  a  Tracelnformatlon 
SEQUENCE  has  t>een  added  by  the  domain  that  last  handled  the  message.  If  the  appropriate 
Tracelnfomnation  was  not  added,  this  should  be  treated  as  a  protocotViolation  (sec.  8.3.2). 

In  addition,  the  relaying  domain  must  checl<  that  the  Information  was  added  in  the  sequence  defined  by 
the  rules  for  adding  Tracelnformatlon  In  the  CCITT  X.400  Implementor's  Guide.  If  the  sequence  is 
lnvalid,then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of  unableToTransfer  and  a 
diagnosticCode  of  InvalidParameters. 

NOTE  -  It  would  be  desirable  for  the  CCITT  to  add  a  diagnostic  code  of  invalidTracelnfbrmation  to  allow  a 
more  meaningful  description  of  this  problem.  A  request  for  this  new  diagnostic  code  will  be  submitted. 


8.3.5  InternalTracelnfo 

This  clause  applies  only  to  MTAs  which  follow  the  agreements  of  clause  7. 

When  a  message  is  accepted  for  relay  from  another  MTA  In  the  domain,  the  relaying  MTA  must  check 
that  an  InternalTracelnfo  SEQUENCE  has  been  added  by  the  MTA  that  last  handled  the  message.  If  the 
appropriate  IntemarTracelnfo  was  not  added,  this  should  be  treated  as  a  protocolVlolatlon  (sec.  8.3.2). 

In  addltton.  the  relaying  MTA  must  check  that  the  information  was  added  In  the  sequence  defined  by  the 
mles  for  adding  Tracelnformatlon  in  the  CCITT  X.400  Implementor's  Guide.  If  the  sequence  Is  Invaiki, 
then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of  unableToTransfer  and  a 
diagnosticCode  of  InvalidParameters. 

NOTE  -  It  would  be  desirable  for  the  CCITT  to  add  a  diagnostic  code  of  invaiidTracelnformation  to  allow 
for  a  more  meaningful  description  of  this  problem.  A  request  for  this  new  diagnostic  code  will  be  submitted. 
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8.3.6       Unsupported  X.400  protocol  elements 

The  protocol  elements  defined  in  X.400  but  unsupported  by  this  profile  are:  the  deferredDelivery  and 
PerOomainBliateralinfo  parameters  of  the  UMPDUEnvelope,  the  ExplicitConversion  parameter  of 
Recipientinfo,  and  the  alternateRecipientAliowed  and  contentRetumRequest  bits  of  the  PerMessageFlag. 
Appropriate  actions  are  described  below  for  domains  that  do  not  support  the  protocol  elements. 


8.3.6.1  deferredDelivery 

The  delivering  domain  shall  do  one  of  the  following: 

a)  deliver  at  once, 

b)  hold  for  deferred  delivery, 

c)  return  a  nondelivery  notification  with  a  ReasonCode  of  unableToTransfer  and  a 
DiagnosticCode  of  noBilateralAgreement. 


8.3.6.2  PerDomainBilaterallnfo 

if  a  delivering  domain  receives  this  element,  the  element  can  be  ignored. 


8.3.6.3  ExplicitConversion 

if  ExplicitConversion  is  requested  the  message  should  be  delivered  if  possible.  That  is,  if  the  UA  is 
registered  to  accept  the  EncodedlnformationTypes  of  the  message,  then  the  message  should  be 
delivered  even  though  the  requested  conversion  could  not  be  performed  along  the  route.  If  delivery  is 
not  possible,  then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of 
conversionNotPerformed  with  no  DiagnosticCode. 


8.3.6.4  alternateRecipientAliowed 

if  a  delivering  domain  receives  this  element  the  element  can  be  ignored. 


8.3.6.5  contentRetumRequest 

if  a  delivering  domain  receives  this  element,  the  element  can  be  ignored. 
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8.3.7       Unexpected  values  for  INTEGER  protocol  elements 

There  are  three  INTEGERS  in  the  PI  Envelope.  Appropriate  actions  are  described  below  for  domains 
receiving  unexpected  values  for  Priority.  ExplicitConverslon,  and  ContentType. 


8.3.7.1  Priority 

Additional  values  for  Priority  have  been  suggested  by  at  least  one  group  of  implementors  as  upward 
compatible  changes  to  the  X.400  Recommendations.  Therefore,  if  a  PRMD  receives  an  unexpected  value 

i{  for  Priority,  and  this  value  is  greater  than  one  byte  in  length,  a  nondelivery  report  should  be  generated 
with  a  ReasonCode  of  unabieToTransfer  and  DiagnosticCode  of  invalidParameters.  If  the  value  is  less 

j  than  or  equal  to  one  byte,  the  PRMD  can  either  generate  a  nondelivery  report  as  previously  specified  or 

jl  interpret  the  Priority  as  normal  and  deliver  or  relay  the  message. 


When  an  unexpected  value  is  received  for  ExplicitConverslon,  it  should  be  handled  as  in  clause  8.3.6.3. 


If  the  ContentType  is  not  supported  by  the  delivering  MTA,  then  a  nondelivery  report  should  be 
generated  with  a  ReasonCode  of  unabieToTransfer,  and  a  DiagnosticCode  of  contentTypeNotSupported. 


8.3.8       Additional  elements 

I  In  the  absence  of  multilateral  agreements  to  the  contrary,  receipt  of  privately  tagged  elements  and 
protocol  elements  in  addition  to  those  defined  in  X.400  will  result  in  a  nondelivery  report  with  a 
ReasonCode  of  unabieToTransfer  and  a  DiagnosticCode  of  invalidParameters. 

The  exceptions  to  this  are  the  MOTIS  elements.  The  treatment  of  MPDU's  containing  these  MOTIS 
extensions  is  described  in  clause  6.11. 


:  8.4  Reports 

There  is  no  mechanism  for  retuming  a  delivery  or  status  report  due  to  errors  in  the  report  itself. 
I  Therefore  the  handling  of  errors  in  reports  is  a  local  matter. 


8.3.7.2 


ExplicitConversion 


8.3.7.3 


ContentType 
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9    MHS  use  of  Directory  Services 


9.1      Directory  service  eiements 

Recommendation  X.4(X}  recognizes  the  need  of  MHS  users  for  a  numt)er  of  directory  service  elements. 
Directory  sen/ice  eiements  are  intended  to  assist  users  and  their  UAs  in  obtaining  information  to  be  used 
in  submitting  messages  for  delivery  by  the  MTS.  The  MTS  may  also  use  directory  service  elements  to 
obtain  infonnation  to  be  used  in  routing  messages.  Some  functional  requirements  of  directories  have 
been  identified  and  are  listed  t)elow: 

a)  Verify  the  existence  of  an  0/R  name. 

b)  Return  the  0/R  address  that  con-esponds  to  the  0/R  name  presented. 

c)  Determine  whether  the  0/R  name  presented  denotes  a  user  or  a  distribution  list. 

d)  Return  a  list  of  the  members  of  a  distribution  list. 

e)  When  given  a  partial  name,  return  a  list  of  0/R  name  possibilities. 

f)  Allow  users  to  scan  directory  entries. 

g)  Allow  users  to  scan  directory  entries  selectively. 

h)  Retum  the  capabilities  of  the  entity  referred  to  by  the  0/R  name. 

i)  Provide  maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a  number  of  operational  aspects  must  be  considered.  These  indude 
user-friendliness,  flexibility,  availability,  expendability.  and  reliability. 

Currently,  these  aspects  of  directory  service  elements  and  procedures  are  under  study  by  tx}th  the 
CCITT  and  the  ISO.  Both  organizations  are  committed  to  the  development  of  a  single  Directory  Service 
specification  for  use  by  MHS  and  all  other  OSI  based  applications. 

Given  the  incomplete  nature  of  the  ongoing  activities  within  the  CCITT  and  the  ISO,  no  implementation 
details  will  be  provided  now  for  MHS  use  of  Directory  Services.  Implementation  agreements  for  MHS 
Use  of  Directory  Sen/ices  will  be  issued  when  current  activities  within  the  CCITT  and  the  ISO  are  stable. 
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9.2      Use  of  names  and  addresses 

It  is  recognized  tliat  these  agreements  enable  a  wide  variety  of  naming  and  addressing  attributes  (see 
sec.  5.3.5  ORName  Protocol  Elements)  wherein  each  PRMD  may  adopt  particular  routing  schemes 
within  its  domain. 

With  the  exception  of  the  intra-domain  connection  agreements: 

a)  These  agreements  make  no  attempt  to  recommend  a  standard  practice  for  electronic  mail 
addressing. 

Inter-PRMD  addressing  may  be  secured  according  to  practices  outside  the  scope  of  these  agreements, 
such  as: 

a)  manual  directories 

b)  on-line  directories 

c)  ORName  address  specifications 

d)  ORName  address  translation. 

Further,  each  PRMD  may  adopt  naming  and  addressing  schemes  wherein  the  user  view  may  take  a  form 
entirely  different  from  the  attributes  reflected  in  table  9.  And,  each  PRMD  may  have  one  user  view  for  the 
originator  form  and  another  for  the  recipient  form,  and  perhaps  other  forms  of  user  addressing.  In  some 
cases  (e.g.,  receipt  notification)  these  user  forms  must  be  preserved  within  the  constraints  of  these 
Implementation  agreements.  However,  mapping  between  one  PRMD  user  form  to  another  PRMD  user 
form,  via  the  X.400  ORName  attributes  of  these  agreements,  is  outside  the  scope  of  these  agreements. 


10  Conformance 


10.1  Introduction 

in  order  to  ensure  that  products  conform  to  these  implementation  agreements,  it  is  necessary  to  define 
the  types  and  degrees  of  conformance  testing  that  products  must  pass  before  they  may  be  classified  as 
conformant.  This  clause  defines  the  conformance  requirements  and  provides  guidelines  for  the 
Interpretation  of  the  results  from  this  type  of  testing. 

This  clause  is  incomplete  and  will  be  enhanced  in  future  versions  of  this  Agreement.  Later  versions  will 
reflect  the  problems  of  conformance  testing  and  will  outline  specific  practices  and  recommendations  to 
aid  the  development  of  conformance  tests  and  procedures. 
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10.2    Definition  of  conformance 

For  this  dause.  the  term  conformance  is  defined  by  the  following: 

a)  The  tests  indicated  for  this  clause  are  intended  to  establish  a  high  degree  of  confidence  in  a 
statement  that  the  implementation  under  test  (lUT)  conforms  (or  does  not  conform)  to  the 
agreements  of  this  clause. 

b)  Conformance  to  a  service  element  means  that  the  information  associated  with  the  service 
element  is  made  accessible  to  the  user  (person  or  process)  whenever  this  agreement  says  that 
this  information  should  be  avaHable.  Accessible  means  that  information  must  be  provided 
descrit}ing  how  a  user  (person  or  process): 

1)  causes  appropriate  information  to  be  displayed,  or 

2)  causes  appropriate  information  to  be  obtained. 

c)  Conformance  to  PI,  P2,  and  RTS  as  part  of  an  X.400  OSI  application  requires  that  only  the 
external  behavior  of  that  OSI  system  adheres  to  the  relevant  protocol  standards.  In  order  to 
achieve  conformance  to  this  clause,  it  is  not  required  that  tlie  inter-layer  interfaces  be  avalable 
for  testing  purposes. 

d)  Conformance  to  the  protocols  requires: 

1)  that  MPDUs  correspond  to  instances  of  syntactically  correct  data  units, 

2)  MPDUs  in  which  the  data  present  in  the  fields  and  the  presence  (or  at>sence)  of 
tliose  fields  is  valid  in  type  and  semantics  as  defined  in  X.400,  as  qualified  by  this  profMe, 

3)  correct  sequences  of  protocol  data  units  in  responses  (resulting  from  protocol 
procedures). 

e)  Statements  regarding  the  conformance  of  any  one  implementation  to  this  proflle  are  not 
complete  unless  a  Protocol  Implementation  Conformance  Statement  (PICS)  is  supplied. 

f)  The  terni  "Implementation  Under  Test"  (lUT)  is  interchangeable  with  the  term  "system"  in  the 
definition  of  conformance,  and  may  refer  to: 

1)  a  domain,  which  may  be  one  or  more  MTA's  with  co-located  or  remote  UA's, 

2)  a  single  instance  of  an  MTA  and  co-located  UA  with  X.400  (PI,  P2,  RTS  and  session) 
software, 

3)  a  relaying  product  with  PI.  RTS  and  session  software. 

4)  a  gateway  product. 

g)  Claiming  implementation  Confonnance 
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1)  An  implementation  wliich  daims  to  be  conformant  as  an  ADMD  must  adiiere  to  the 
agreements  in  clauses  5  and  6. 

2)  An  implementation  which  claims  to  be  conformant  as  a  PRMD  must  adhere  to  the 
agreements  in  clause  5. 

3)  An  implementation  which  claims  to  be  conformant  as  a  relaying  PRMD  must  adhere 
to  the  agreements  in  clause  5  and  the  appropriate  clauses  of  7. 

4)  An  implementation  which  claims  to  be  conformant  to  the  intra-domain  connection 
agreements  must  adhere  to  the  agreements  in  clause  5  and  the  appropriate  clauses  of 
7. 


10.3    Conformance  requirements 


10.3.1  introduction 

Conformance  to  this  specification  requires  that  all  the  services  listed  as  supported  in  clauses  5,  6,  and  if 
appropriate,  7  of  these  agreements  are  supported  in  the  manner  defined,  in  either  the  CCITT  X.400 
Recommendations  or  these  agreements.  It  is  not  necessary  to  implement  the  recommended  practices  of 
annex  B,  in  order  to  conform  to  these  agreements. 

;|  It  is  the  intention  to  adopt,  where  and  when  appropriate  the  testing  methodology  and/or  the  abstract 
test  scenarios  currently  being  defined  by  the  CCITT  X.400  Conformance  Group.  However,  it  is 
recognized  that  formal  CCITT  Recommendations  relating  to  X.400  Conformance  Testing  will  not  be 
available  until  1988.  It  is  also  recognized  that  aspects  of  these  agreements  are  outside  the  scope  of  the 
CCITT,  and  that  other  organizations  will  have  to  provide  conformance  tests  in  these  cases. 


10.3.2     Initial  conformance 

This  clause  is  intended  to  provide  guidelines  to  vendors  who  envisage  having  X.400  products  available 
prior  to  any  formal  mechanism,  or  "Conformance  Test  Center"  t>eing  made  accessible  that  would  allow 
for  conformance  to  this  product  specification  to  be  tested. 

It  is  feasible  that  vendors  and  carriers  will  want  to  enter  bilateral  test  agreements  that  will  allow  for  initial 
trials  to  be  carried  out  for  the  purposes  of  testing  initial  intenA^orking  capabilities.  It  is  equally  feasible  that 
for  the  purposes  of  testing  interoperability,  only  a  subset  of  this  specification  will  initially  be  tested. 

NOTE  -  By  claiming  conformance  to  this  subset  of  information  the  vendor  or  carrier  CANNOT  claim 
conformance  to  this  entire  specification. 

There  are  two  aspects  to  the  requirements,  intenworking  and  sen/ice,  as  described  in  the  following 
clauses. 
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10.3.2.1  Interworking 

The  interworking  requirements  for  confomnance  implies  that  tests  be  done  to  checic  for  the  syntax  and 
semantics  of  protocol  data  elements  for  a  system  as  defined  by  the  classification  scheme  of  clauses 
5.2.1.1  and  7.5.2.  For  a  relay  system,  the  correct  protocol  elements  should  be  relayed  as  appropriate. 
For  a  recipient  system,  a  message  with  correct  protocol  elements  must  not  be  rejected  where 
appropriate. 

10.3.2.2  Service 

For  information  available  to  the  recipients  via  the  IPMessage  Heading  and  Body,  the  following  should  be 
made  accessible: 

a)  IPMessage  ID  -  only  the  PrintableString  portion  of  the  IPMessageld  needs  to  be  accessible. 

b)  subject, 

c)  primaryRecipients, 

d)  copyRecipients, 

e)  t)lindcopyRecipients, 

f)  authorizingUsers, 

g)  originator, 

h)  InReplyTo, 

i)  replyToUsers, 
j)  importance, 
k)  sensitivity, 

i)  iA5Text  Bodypart. 
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Annex  A  (normative)  

Interpretation  of  X.400  service  elements 

The  work  on  service  element  definitions  is  iimited  to  those  that  are  defined  as  "supported"  in  clause  5  of 
this  specification.  Furthermore  it  is  not  the  intent  of  this  clause  to  define  how  information  should  t>e 
made  available  or  presented  to  a  MHS  user,  nor  is  it  Intended  to  define  how  individual  vendors  should 
design  their  products.  In  addition,  statements  on  conformance  to  a  specific  sen/ice  element  and  the 
allocation  of  error  codes  that  are  generated  as  a  result  of  violations  of  the  sen/ice  should  be  defined  in 
the  clauses  on  conformance  and  errors  as  part  of  the  main  product  specification.  The  main  objective  is 
to  provide  clarification,  where  required,  on  the  functions  of  a  service  element,  and  in  particular  what  the 
original  intent  of  the  Recommendations  were. 


A.1     Service  elements 

The  following  Sen/ice  Elements  defined  in  X.400  have  been  examined  and  require  further  text  to  be 
added  to  their  definitions  to  represent  the  proposed  implementation  of  these  service  elements  by  the 
X.400  SIG. 

The  sen/ice  element  clarifications  are  to  be  taken  in  the  context  of  this  profile. 
Sen/ice  elements  not  referenced  in  this  clause  are  as  defined  in  X.400. 


A.2  Probe 

A  PRMD  need  not  generate  probes. 

If  a  probe  is  addressed  to  and  received  by  a  PRMD.  the  PRMD  must  respond  with  a  Delivery  Report  as 
appropriate  at  the  time  the  prot>e  was  processed. 


A.3     Deferred  delivery 

In  the  absence  of  bilateral  agreements  to  the  contrary.  Deferred  Delivery  and  Deferred  Delivery 
Cancetlation  are  local  matters  (i.e.,  confined  to  the  originating  domain)  and  need  not  be  provided. 

The  extension  of  Deferred  Delivery  beyond  the  boundaries  of  the  initiating  domain  is  via  bilateral 
agreement  as  specified  in  section  3.4.2.1  of  X.411. 


59 


Part  7: 1984  Message  Handling  Systems 


December  1992  (Stable) 


A.4     Content  type  indication 

It  is  required  that  boVn  an  originating  and  recipient  domain  be  able  to  support  P2  content  type.  Tlie 
ability  for  domains  to  be  able  to  exchange  content  types  other  than  P2  will  depend  on  the  existence  of 
bilateral  or  multi-lateral  agreements. 


A.5     Original  encoded  information  types  indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to  support  IA5  text.  Support  for  other 
encoded  information  types,  for  the  purposes  of  message  transfer  between  domains,  will  depend  on  the 
existence  of  bilateral  or  multi-lateral  agreements. 

The  use  of  the  "unspecified"  form  of  encoded  information  type  should  only  be  used  when  the  UMPDU 
content  represents  an  SR-UAPDU  or  contains  an  auto-forwarded  IM-UAPDU. 

The  original  encoded  information  type  of  a  message  is  not  meaningful  unless  a  message  is  converted  en 
route  to  the  recipient.  These  agreements  support  only  IA5  text,  which  should  not  undergo  conversion. 
The  original  encoded  information  types  should  be  made  accessible  to  the  recipient  for  upward 
compatibility  with  the  use  of  non-IA5  text  message  body  parts. 


A.6      Registered  encoded  information  types 

A  UMPDU  with  an  "unspecified"  value  for  Original  Encoded  Information  Type  shall  be  delivered  to  the 
UA. 


A.7      Delivery  notification 

The  UAContentID  may  be  used  by  the  recipient  of  the  delivery  notification  for  correlation  purposes. 


A.8      Disclosure  of  other  recipients 

This  service  is  not  made  available  by  originating  MTAE's  to  UAE's,  but  must  be  supported  by  relaying 
and  recipient  MTAE's. 

By  supporting  the  disclosure  of  other  recipients  the  message  recipient  can  be  informed  of  the  0/R 
names  of  the  other  recipient(s)  of  the  message,  as  defined  in  the  P1  envelope,  in  addition  to  the  0/R 
Descriptors  within  the  P2  header. 

These  agreements  do  not  support  initiation  of  disclosure  of  other  recipients,  but  the  information 
associated  with  it  should  be  made  accessible  to  the  recipient  for  upward  compatibility  with  support  for 
the  initiation  of  this  service  element. 
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A.9     Typed  body 

As  defined  in  X.400  witli  tlie  addition  of  the  Private  Body  Types  that  are  to  be  supported.  At  present 
there  is  no  mechanism  provided  within  X.420  that  would  aliow  you  to  respond  to  reception  of  an 
unsupported  body  type. 


A.10    Blind  copy  recipient  indication 

it  shouid  be  considered  that  the  recipient's  UA  acts  on  behalf  of  the  recipient,  and  therefore  may  choose 
to  disclose  ail  BCC  recipients  to  each  other.  Therefore  it  is  tlie  responsibility  of  the  originating  domain  to 
submit  two  or  more  messages,  depending  on  whether  or  not  each  BCC  should  be  disclosed  to  each 
other  BCC. 


A.11    Auto  forwarded  indication 


A  UA  may  choose  not  to  fonvard  a  message  that  was  previously  auto-forwarded.  In  addition  there  is  no 
requirement  for  an  IPM  UA  that  does  not  support  non-receipt  or  receipt  notification  to  resporxJ  with  a 
non-receipt  notification  when  a  message  is  auto-fonwarded. 


A.12    Primary  and  copy  recipients  indication 

It  is  required  that  at  least  one  primary  recipient  be  specified;  however,  for  a  forwarded  message  this 
need  not  be  present.  The  recipient  UA  should  be  prepared  to  accept  no  primary  and  copy  recipients  to 
enable  future  interworking  with  Teletex,  Fax.  etc. 


A  message  originator  should  make  no  assumpttons  as  to  the  semantic  Interpretation  by  the  recipients 
UA  regarding  classifications  of  sensitivity.  For  example,  a  personal  message  may  be  printed  on  a  shared 
printer. 


Action  taken  in  this  situation  is  a  local  matter. 


A.13    Sensitivity  indication 
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A.14    Reply  request  indication 

In  requesting  this  service  an  originator  may  additionally  supply  a  date  by  which  the  reply  should  be  sent 
and  a  list  of  the  Intended  recipients  of  the  reply.  If  no  such  list  is  provided  then  the  initiator  of  the  reply 
sends  the  reply  to  the  originator  of  the  message  and  any  recipients  the  reply  initiator  wishes  to  include. 
The  replytoUsers  and  the  repiyBy  date  may  be  specified  without  any  explicit  reply  t>eing  requested.  This 
may  be  interpreted  by  the  recipient  as  an  implicit  reply  request.  Note  that  for  an  auto-fon/varded 
message  an  explicit  or  implicit  reply  request  may  not  be  meaningful. 


A.15    Body  part  encryption 

The  original  encoded  information  type  indication  includes  the  encoded  information  type(s)  of  message 
body  parts  prior  to  encryption  by  the  originating  domain.  The  ability  for  the  recipient  domain  to  decode 
an  encrypted  body  part  is  a  local  matter.  Successful  use  of  this  facility  can  only  be  guaranteed  if  there 
exists  bilateral  agreements  to  support  the  exchange  of  encrypted  body  parts. 


A.16    Forwarded  IP  message  indication 

I 

The  following  use  of  the  original  encoded  information  type  in  the  context  of  forwarded  messages  is 
clarified: 

a)  If  fcPA^arding  a  private  message  body  part  the  originator  of  the  fonA^arded  message  shall  set 
the  original  encoded  information  types  in  the  PI  envelope  to  undefined  for  that  body  part.  ' 

b)  The  encoded  information  types  of  the  message  being  forwarded  should  be  reflected  In  the 
new  original  encoded  information  types  being  generated.  ^ 

c)  See  ammex  B  on  recommended  practices  for  the  use  of  the  delivery  information  as  part  of  1 
Forwarded  IP-message.  | 


A.17    Multipart  body 

It  is  the  intent  of  multipart  bodies  to  allow  for  the  useful  and  meaningful  structuring  of  a  message  that  is  » 
constructed  using  differing  body  part  types.  For  example,  it  is  not  recommended  that  a  message  made 
up  of  only  IA5  text  should  be  represented  as  a  number  of  IA5  body  parts,  each  one  representing  a 
paragraph  of  text. 
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Annex  B  (informative)  

Recommended  X.400  practices 

It  is  not  necessary  to  follow  the  recommended  practices  when  claiming  conformance  to  tliese 
j  agreements. 


B.I     Recommended  practices  in  P2 


B.1.1  ORDescriptor 

Vendors  following  the  OSI  Implementors'  Worl(shop  guidelines  shall,  whenever  possit)le,  generate  the 
ORName  portion  of  an  ORDescriptor  in  ALL  IPM  heading  fields. 


B.I  .2      ForwardedlPMessage  BodyParts 

FonwardedlPMessage  BodyParts  should  be  nested  no  deeper  than  eight.  There  is  no  restriction  on  the 
numt)er  of  FonwardediPMessage  BodyParts  at  any  given  depth. 


B.I  .3  Dellverylnformation 

it  is  strongly  recommended  that  Deliverylnformation  t>e  supplied  in  t>oth  fonwarded  and  autoforwarded 
message  body  parts.  Deiiverylnformation  Is  useful  when  a  message  has  multiple  fonwarded  message 
body  parts  because  without  it,  the  EncodedinfformationType(s)  of  the  component  fonwarded  messages 
cannot  be  deduced  easily.  Deiiverytnfonfnatlon  is  useful  for  autoforwarded  messages  because  the 
EncodedlnformationType  of  an  autoforwarded  message  is  "unspecified"  and  the 
EncodedinformationType(s)  of  the  message  cannot  be  determined  easily  without  it.  Absence  of  the 
EncodedinfonnationType(s)  makes  It  difficult  for  a  UA  to  easily  determine  whether  the  message  can  be 
rendered. 


B.2     Recommended  practices  in  RTS 


B.2.1  S-U-ABORT 

In  the  case  where  S-U-ABORT  indicates  a  temporaryProblem,  reestablishment  of  the  session  should  not 
be  attempted  for  a  "sensible"  time  period  (typically  not  less  than  5  min).  In  instances  where  this  delay  is 
not  required  or  necessary,  report  a  localSystemProblem. 
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B.2.2  S-U-EXCEPTION-REPORT 

S-U-EXCEPTtON-REPORT  reason  codes  can  be  interpreted  as  follows: 

B.2.2.1        receiving  ability  jeopardized  (value  1) 

Possible  meaning:  The  receiving  RTS  knows  of  an  impending  system  shutdown. 

B.2.2.2        local  ss-User  error  (value  5) 

Possik)le  meaning:  The  receiving  RTS  needs  to  resynchronize  the  session  dialogue. 
B.2.2.3       irrecoverable  procedure  error  (value  6) 

Possible  meaning:  The  receiving  RTS  has  had  to  delete  a  partially  received  APDU,  even  though  some 
minor  synchronization  points  have  been  confirmed. 

B.2.2.4       non  specific  error  (value  0) 

Possible  meaning:  The  receiving  RTS  cannot  handle  the  APDU  (for  example,  t>ecause  it  was  too  large) 
and  wishes  to  inform  the  sending  RTS  not  to  try  again. 

B.2.2.5       sequence  error  (value  3): 

Possible  meaning:  The  S-ACTIViTY-RESUME  request  specified  a  minor  synchronization  point  serial 
number  which  does  not  match  the  checkpoint  data. 

B.2.3      OSi  addressing  Information 

For  purposes  of  kJentifying  an  MTA  during  an  RTS  Open,  OSI  addressing  information  should  be  used. 
This  addressing  information  is  conveyed  by  lower  layer  protocols  and  is  reflected  by  the  calling  and 
called  SSAP  parameters  of  the  S-CONNECT  primitives. 

MTA  valuation  and  Mentification  are  related,  but  separate,  functions.  The  mTAName  and  password 
protocol  elements  of  the  RTS  user  data  should  be  used  for  validation,  rather  that  identification,  of  an 
MTA.  The  RTS  initiator  and  responder  may  independently  require  each  other  to  supply  mTAName  and 
password. 

The  CallingSSUserReference  parameter  of  the  S-CONNECT  primitives  should  only  have  meaning  to  the 
entity  that  encoded  it  and  should  not  be  used  to  kJentify  an  MTA. 
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B.3     Recommended  practices  for  ORName 

i  Table  9  stipulates  that  the  StandardAttributeLlst  must  contain  either  PrivateDoniainName  or 
OrganizationName.  It  is  recommended  that,  for  both  originator  and  recipients  in  a  private  domain,  the 
PrivateDomainName  field  be  used. 

It  Is  recommended  that  there  should  be  a  DomalnDeflnedAttribute  to  be  used  in  addressing  UAs  in 
^stlng  maH  systems,  in  order  to  curtail  the  proliferation  of  different  types  of  DomainDefinedAttributes 
I  used  for  the  same  purpose.  The  syntax  of  this  DomalnDeflnedAttribute  conforms  to  the  CCITT  Pragmatic 
I  Constraints,  and  thus  has  a  maximum  value  length  of  128  octets  and  a  type  length  of  8  octets,  each  of 
I  type  Printable  String.  Only  one  occurrence  is  allowed. 

This  DomalnDeflnedAttribute  has  the  type  name  'ID'  (in  uppercase),  it  contains  the  unique  identifier  of 
\  the  UA  used  in  addressing  within  the  domain.  This  DomalnDeflnedAttribute  is  to  be  exclusively  used  for 
!  routing  within  the  destination  domain  (i.e.,  once  routed  to  that  domain  via  the  mandatory  components  of 

the  StandardAttributeUst);  any  other  components  of  the  StandardAttributeUst  may  be  provided.  If  they 
'  conflict  delivery  Is  not  made. 

The  contents  of  this  parameter  need  not  be  validated  In  the  originating  domain  or  any  relaying  domain, 

i  but  simply  transferred  Intact  to  the  next  MTA  or  domain. 

j 

I  Class  2  and  class  3  MTAs  In  a  PRMD  should  allow  administrators  to  decide  the  number  of 
OrganizatlonalUnlts  that  should  appear  in  user  names,  instead  of  imposing  a  software  controlled  limit 

i  which  is  less  than  four.  This  is  desirable  because  when  two  different  vendors  impose  different  limits  on 
the  number  of  OrganizationaiUnlts  in  a  name,  it  becomes  difficult  for  the  administrator  to  choose  a 
sensible  naming  scheme. 

There  are  existing  mail  systems  that  Include  a  small  set  of  non-Printable  String  characters  In  their 
identifiers.  For  these  systems  to  communicate  with  X.400  messaging  systems,  either  for  pass-through 
sen/Ice  or  delivery  to  X.400  users,  gateways  will  be  employed  to  encode  these  special  characters  into  a 

I  sequence  of  Printable  String  characters.  This  conversion  should  be  performed  by  the  gateway 
according  to  a  common  scheme  and  before  insertion  in  the  ID  DDA,  which  is  intended  to  carry 

I  electronic  mail  Identifiers.  X.400  User  Agents  may  also  wish  to  perform  such  conversions. 

I  It  Is  recommended  that  the  following  symmetrical  encoding  and  decoding  algorithm  for  non-Printable 
String  characters  be  employed  by  gateways.  The  encoding  algorithm  maps  an  ID  from  an  ASCII 
representation  to  a  PrintableStrIng  representation.  Any  non-printable  string  characters  not  specified  in  the 

1^  table  are  covered  by  the  category  'other*  In  the  table  t>elow. 

^'  The  principal  conversion  table  for  the  mapping  is  as  follows: 
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Table  8.1  -  Printable  String  to  ASCII  mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

§  (at  sign) 

(a) 

1  (exclamation) 

(b) 

"  (quote  nark) 

(q) 

(underline) 

(u) 

(  (left  paren.) 

(1) 

)  (right  paren.) 

(r) 

other 

(3DI6IT) 

where  SDIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal  encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  Printat}leString,  the  tat)le  and  the  fotlowing  algorithm  should  be 
used: 


IF  current  character  is  in  the  encoding  set  THEN 
encode  the  character  according  to  the  table  above 
ELSE 

write  the  current  character; 
continue  reading; 


To  decode  a  PrintableString  representation  to  an  ASCII  representation,  the  table  and  the  following 
algorithm  should  be  used: 


IF  current  character  is  not  THEN 
write  character 

ELSE 

{ 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  the  above  table  THEN 

decode  per  above  table 
ELSE 

^    write  current  character; 
continue  reading; 


Qass  2  and  class  3  MTAs  in  a  PRMD  should  allow  administrators  to  decide  the  number  of 
OrganizationalUnits  that  should  appear  in  user  names,  instead  of  imposing  a  software  controlled  limit 
which  is  less  than  four.  This  is  desirable  because  when  two  different  vendors  impose  different  limits  on 
the  number  of  OrganizationalUnits  in  a  name,  it  becomes  difficult  for  the  administrator  to  choose  a 
sensible  naming  scheme. 
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B.4     Postal  addressing 

For  domains  wishing  to  support  postal  (or  physical)  delivery  options,  the  following  interim  set  of 
'nationally-defined'  domain  defined  attributes  are  recommended.  The  CCITT  will  define  Standard 
Attributes  in  support  of  physical  delivery  in  its  1988  Recommendations;  this  is  only  an  Interim  solution. 

CCITT  will  also  be  addressing  the  sen/lces  associated  wit:h  physical  delivery.  This  interim  solution  does 
not  address  the  end-to-end  sen/ice  aspects  of  physical  delivery;  in  particular,  the  following  IPM  service 
elements  do  not  currently  extend  outside  of  the  X.400  environment: 

a)  alternate  Recipient  Assignment 

b)  PROBE 

c)  Receipt  Notification  /  Non-Receipt  Notifications 

d)  Grade  of  delivery 

'Delivery"  means  passing  a  message  from  the  MTS  to  the  physical  delivery  system  (PDS),  and  not  to  the 
user  (or  user  agent). 

The  following  three  DDAs  are  recommended  to  be  used  to  specify  a  postal  (or  physical)  address: 

CNTRPC  encodes  the  country  and  postal  code  for  postal  delivery.  The  DDA  value  is  of  the  form 
"Country?Postalcode"  (for  example,  "USA722096").  The  country  field  is  optional,  the  postal  code  Is 
optional;  the  separator  ("?")  is  not.  If  both  country  and  postal  code  are  missing,  this  DDA  should  not  be 
specified. 

PDA1  The  country  and  postal  code  fields  are  free-form  text. 

PDA2  These  two  DDA  (signifying  Postal  Delivery  Address  strings  1  and  2)  form  a  256  character  free- 
form  postal  address.  Fields  are  separated  by  a  question  mark  ("?").  There  is  no  implied  seF)arator 
between  PDA1  and  PDA2.  The  meaning  of  the  fields  are  defined  by  each  domain  supporting  the  physical 
delivery  interface.  PDA1  contains  the  first  128  characters,  PDA2  the  next  128  characters.  If  the  PDA 
string  is  less  than  128  characters,  PDA2  Is  not  used. 

For  example,  if  the  domain  Interprets  the  PDA  fields  as  lines,  the  address 

Mr.  John  Smith 
Conway  Steel 
123  Main  Street 
Reston  VA  22096 

would  be  encoded  as  follows: 
type     =  "PDAl" 

value    =  "Mr.  John  Smith?Conway  Steel?123  Main  Street?Reston  VA" 
CNTRPC  =  "?22096" 
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B.5     EDI  use  of  X.400 


B.5.1       Introduction  and  scope 

This  is  a  guideline  for  EDI  data  transfer  in  an  X.400  environment  confomning  to  the  NiST  agreements. 
These  recommended  practices  outline  procedures  for  use  in  transferring  EDI  transactions  t>etween 
trading  partner  applications  in  an  attempt  to  fecUitate  actual  X.400  Implementation  by  EDI  users. 

The  scope  of  this  guideline  is  to  describe  specific  recommendations  for  adopting  X.400  as  the  data 
transfer  mechanism  between  EDI  applications. 


B.5.2  Model 


The  MHS  recommendations  can  accommodate  EDI  through  the  approach  illustrated  below.  Many 
Message  Transfer  (MT)  service  elements  defined  in  the  X.400  recommendations  are  particularly  useful  to 
the  EDI  application. 


x.400  Message  (1  EDI  interchange) 


Envelope   > 


PI  Control 
Information 


Content   > 


One 
EDI 

Interchamge 


MHS  Message 


This  diagram  depicts  an  EDI  content  (1  EDI  interchange)  enveloped  by  the  P1  MHS  envelope.  All  the  MT 
Services  defined  In  the  X.400  Recommendations  may  be  used  for  EDI.  However,  it  is  not  required  to 
support  optional  or  non-essential  services  to  exchange  EDI  data  between  EDI  users.  When  an  EDI  user 
submits  an  EDI  Trade  Document  to  the  EDI  User  Agent,  the  EDI  UA  will  submit  the  EDI  content  plus  PI 
envelope  to  the  Message  Transfer  System  (MTS). 
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The  EDI  UA  must  support  the  essential  MT  Services  as  defined  in  these  Agreements;  for  example,  as  a 
minimum,  to  provide  default  values  for  services  not  elected  by  the  EDI  user,  such  as  Grade  of  Delivery. 


NOTE  -  MT  Services  are  not  necessarily  made  available  by  the  EDI  UA  to  the  EDI  user. 


B.5.3      Protocol  elements  supported  for  EDI 

The  following  PI  protocol  elements  will  be  used  to  support  EDI  applications: 


B.5.3.1        Content  type 

For  EDI  applications,  the  content  type  will  be  0  (undefined  content). 


1  B.5.3.2       Original  encoded  information  types 

Any  EIT  defined  in  the  X.400  Recommendations  may  be  used  to  specify  the  encoding  of  EDI  content. 
•  However,  for  ANSI  X12  EDI  applications  in  particular,  it  is  expected  that  the  "undefined"  and  "laSText" 
I   EIT's  will  normally  be  used,  with  "undefined"  used  to  signify  the  EBCDIC  character  set. 


B.5.4      Addressing  and  routing 

I  It  is  anticipated  that  connection  of  some  existing  systems  to  an  X.400  service  for  EDI  purposes  will  be  by 
other  than  X.400  protocols,  at  least  in  the  short  term. 

tj 

I  EDI  messages  entering  the  X.400  environment  will  therefore  need  to  have  X.400  0/R  Names  added  to 
f  identify  the  origination  and  recipient  trading  partners,  typically  by  means  of  local  directory  services  in  the 

origination  domain  which  will  map  EDI  identifiers/addresses  into  0/R  Names.  Such  0/R  Names  will 
*i  contain  Standard  Attributes  as  defined  in  tab>le  9  and  for  recipient  trading  partners  will  at  least  identify 
j  the  destination  domain. 

I  In  the  case  of  trading  partners  outside  the  X.400  environment,  it  is  expected,  however,  that  there  will  be 
i  cases  where  message  delivery  will  require  the  provision  of  addressing  information  beyond  that  which 
■  can  be  carried  in  Standard  Attributes.  In  such  cases.  Domain  Defined  Attributes  are  recommended  to  be 
used. 
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The  syntax  of  this  DDA  Is  as  defined  in  tabUe  9,  with  a  single  occun-ence  having  the  type  name  "EDI" 
(uppercase)  and  a  value  containing  the  Identifier/address  of  the  trading  partner.  For  ASC  X12  purposes, 
specifically,  this  value  will  comprise  the  2  digit  interchange  ID  qualifier  followed  by  the  interchange  ID 
(max  15  characters).  Routing  on  this  DDA  shall  only  occur,  if  at  all,  in  the  destination  domain. 


B.6     USA  body  parts 

It  is  recommended  thiat  UAs  can  generate  any  USA  Body  Part,  as  defined  In  clause  5.3.6.2,  and  that  they 
can  receive  such  body  parts  as  well,  reception  of  USA  Body  Parts  does  not  imply  further  processing  by 
the  UA,  but  merely  that  the  body  part  is  made  available,  with  a  Indication  of  Its  registered  txxJy  part 
identifier,  to  another  process  or  deposition  in  a  file.  Generation  Implies  the  reverse  of  this  process. 


B.7     Recommended  practices  for  binary  data  transfer 

The  capability  to  transfer  binary  data,  such  as  those  generated  by  word/document  processing, 
spreadsheets,  or  graphics  applications  among  X.400  system  Is  a  useful  and  desirable  feature.  Many 
messaging  systems  provide  such  capability  today. 

It  is  recommended  tiiat  transfer  of  binary  data  through  1984-based  systems  be  achieved  using  the 
unidentified  BodyPart  In  P2  with  the  ASN1  definition  recaptured  as  follows: 


BodyPart 

:;=    CHOICE  { 

[0]  IMPLICIT  lASText 

[14]  IMPLICIT  Unidentified 

...  } 

: : =    OCTET  STRING 

Unidentified 

NOTE  -  the  Unidentified  BodyPart  is  included  in  1984  X.400  Implementor's  Guide,  Version  6,  and  is 
renamed  as  BilaterallyDefinedBodyPart  in  1988  X.400  Series  with  the  same  tag  and  definition. 

Additionally  the  binary  data  can  be  identified  by  a  text  string  in  the  subject  heading  or  in  an  lASText  body 
part  preceding  the  Unidentified  BodyPart. 

When  the  Unidentified  BodyPart  is  present  in  a  P2  message,  the  undefined(O)  bit  of  the  PI 
EncodedlnformationTypes  will  be  set.  If  the  lASText  bodypart  is  also  present,  the  IAStext(2)  bit  will  also  be 
set. 

The  binary  data  is  the  raw  data  as  generated  by  user  applications.  Besides  encapsulating  it  for  transfer 
purposes,  X.400  systems  do  not  encode  or  interprete  the  binary  data  in  any  way  further.  How  the  data  is 
encoded  or  decoded  is  defined  by  the  cooperating  user  applications.  How  the  data  is  injected  into  X.400 
systems  or  transferred  out  of  X.400  systems  to  the  user  applications,  or  how  the  user  applications  are 
invoked  to  process  the  data  is  a  local  implementation  issue  and  not  defined. 
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B.8     Recommended  practice  for  Office  Document  Architecture 
(ODA)  transfer 

It  is  recommended  that  the  conveyance  of  ODA  documents  through  1984-based  X.400  systems  be 
achieved  using  the  following  schemes: 

B.8.1       ODA  In  P2 

An  ODA  document  will  be  transferred  as  a  single  body  part  with  tag  1 2,  recaptured  as  follows: 


BodyPart 

::=    CHOICE  { 

[0]  IMPLICIT 

lASText 

oda 

[12]  IMPLICIT 

OCTET  STRING 

...  } 

The  content  of  the  Octet  String  will  contain  a  value  of  type  OdaBodyPart  as  follows: 


OdaBodyPart 

::=    SEQUENCE  { 

OdaBodyPartParameters , 

OdaData  } 

The  Parameters  and  Data  components  are  defined  in  Annex  E  of  CCITT  Recommendation  T.411  (1988) 
(ISO  8613-1). 


\  B.8.2       ODA  In  PI 

The  undefined  bit  (bit  0)  of  the  EncodedlnformationTypes  must  be  set  and  the  ODA  bit  (bit  10)  of  the 
EncodedlnformationTypes  should  be  set  when  an  ODA  document  is  present  in  P2.  However,  MTAs 
should  be  tolerant  of  messages  containing  ODA  documents  being  received  with  just  the  undefined  bit 
(bit  0)  set,  and  should  still  deliver  the  message. 


^  B.8.3       Interworking  with  later  versions  of  X.400 

i!  The  1988  X.419  Recommendation  acknowledges  that  a  1984  system  may  receive  messages  containing 
new  distinguished  [integer]  values  that  it  is  not  expecting,  and  that  this  may  result  in  service 
in'egularities.  It  is  implied  that  it  would  be  optimal  for  1984  systems  to  accept  these  unexpected  integer 
values  if  at  all  possible.  (Note  clause  8.3.7  of  this  section  describes  appropriate  actions  for  unexpected 
values  of  the  INTEGER  fields  in  the  PI  envelope.)  No  downgrading  should  be  done  for  these  values 
when  passing  affected  messages  from  newer  systems  to  older  systems. 
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Annex  C  (normative)  

Rendition  of  lASText  and  T61  String  characters 


C.1      Generating  and  imaging  lASText 

The  characters  that  may  be  used  in  an  lASString  are  the  graphic  characters  (including  Space),  control 
characters  and  Delete  of  the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  nnay  be  used  with  a  guaranteed  rendition  are  those  related  with  positions 
2/0  to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code  table. 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a  subset  consisting  of  the 
format  effectors  0/10  (LF),  0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the  following 
combinations: 


CR 

LF 

to  start  a  new  line 

CR 

FF 

to  start  a  new  page  (and  line) 

LF 

..  LF 

to  show  empty  lines  (always  after  one  of  the 

preceding  combinations). 

The  other  control  characters  or  the  above  control  characters  in  different  combinations  may  be  used  but 
have  no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The  lASString  in  a  P2  lASText  BodyPart 
represents  a  series  of  lines  which  may  be  divided  into  pages.  Each  line  should  contain  from  0  to  80 
graphic  characters  for  guaranteed  rendition.  Longer  lines  may  be  arbitrarily  broken  for  rendition.  Note 
that  X.408  states  that  for  conversion  from  lASText  to  Teletex,  the  maximum  line  length  is  77  characters. 


C.2     Generating  and  imaging  T61  String 

For  further  study. 
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Annex  D  (informative)  ^  

Differences  in  interpretation  discovered  tlirougii  testing  of  the  MHS  for 
the  CeBit  1987  demonstration 

Several  interworking  problems  were  discovered  through  multi-verxJor  testing.  These  problems.  arxJ 
recommendations  for  solutions  to  them  are  discussed  in  this  annex. 


D.I     Encoding  of  RTS  user  data 

The  password  is  defined  as  an  ANY  in  the  X.400  Recommendations,  and  implementor's  groups  have 
decided  to  use  an  lASStrlng  for  this  field.  There  was  some  confusion  about  what  the  X.409  encoding  for 
this  lASString  would  be,  and  the  correct  encoding  is: 


class; 

context  specific 

form: 

constructor 

id  code: 

1 

length: 

length  of  contents 

contents : 

(primitive  encoding) 

lASString: 

16 

length : 

length  of  contents 

contents : 

the  password  string 

class: 

context  specific 

form: 

constructor 

id  code: 

1 

length : 

length  of  contents 

contents : 

(constructor  encoding)  left  as  an  exercise  for  the  reader 

Implementations  should  be  prepared  to  receive  any  X.409  type  for  the  password  because  of  its  definition 
as  an  ANY. 


D.2     Extra  session  functional  units 

One  verxior  proposed  more  than  the  required  set  of  functional  units  on  opening  the  session  connection, 
and  the  receiver  rejected  the  connection.  All  debate  aside  about  whether  the  initiator  should  have 
proposed  units  outside  of  the  required  set.  or  whether  the  receiver  should  have  rejected  the  connection, 
the  set  of  functional  units  can  be  negotiated  In  a  straightforward  way.  The  following  is  recommended. 

If  the  Initiator  proposes  using  more  than  the  required  set  of  functional  units,  the  responder  should 
specify  the  set  of  functional  units  that  it  would  like  to  use  (which  should  include  the  required  set)  in  the 
open  response.  The  session  Implementations  will  automatically  use  the  intersection  of  the  units  proposed 
by  both  sides. 

If  the  initiator  proposes  using  less  than  the  required  set  of  functional  units,  the  responder  shoukj  reject 
the  connection.  Unfortunately,  there  is  not  an  appropriate  RefuseReason  for  rejecting  the  connection,  so 
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instead  of  refusing  tlie  connection  in  the  response  to  the  S-CONNECT,  tlie  receiver  should  issue  an  S-U-  ! 

ABORT  with  an  AbortReason  of  protocolError.  Note  that  it  is  valid  to  issue  an  S-U-ABORT  instead  of  ) 
responding  to  the  S-CONNECT.  A  problem  report  has  been  submitted  to  the  CCiTT  requesting  the 

addition  of  a  RefuseReason  for  this  situation.  i 

If  the  responder  proposes  using  less  than  the  required  set  of  functional  units,  the  session  connection  Is 
established  before  the  initiator  can  check  for  this.  If  too  few  functiortai  units  have  been  proposed,  the 
initiator  should  abort  the  connection  using  S-U-ABORT,  with  an  abort  reason  of  protocolError. 

D.3     Mixed  case  in  the  MTA  name  i 

The  MTA  name  is  frequently  exchanged  over  the  telephone  when  two  systems  are  being  configured  to  i 

communicate  with  one  another,  in  one  such  telephone  exchange,  the  casing  of  the  MTA  name  was  not  | 

specified,  the  MTA  name  consisted  of  both  upper  and  lower  case  letters,  and  one  of  the  implementations  i 

compared  MTA  names  for  equality  in  a  case  sensitive  manner.  Consequently,  connections  failed  until  the  ^ 

problem  was  detected  and  repaired.  It  Is  recommended  that  the  MTA  name  be  compared  for  equality  in  i 

a  case  insensitive  manner,  and  that  the  password  be  compared  for  equality  in  a  case  sensitive  manner,  i 


D.4     X.41 0  activity  identifier  | 

The  X.400  Implementor's  Guide  recommends  that  the  activity  identifier  be  X.409  encoded,  but  this  is  only 
a  recommendation  and  not  a  requirement.  Consequently,  receiving  systems  cannot  assume  that  the 
activity  identifier  will  be  X.409  encoded. 

Encoding  of  per  recipient  flag  and  per  message  fFlag  { 
In  the  definition  of  the  PerRecipientFlag  in  X.41 1 ,  there  is  a  statement  that  the  last  three  bits  are 
reserved,  and  should  be  set  to  zero.  It  is  unclear  whether  those  bits  are  unused  in  the  X.409  encoding. 
Receivers  should  accept  encodings  with  either  zero  or  three  unused  bits.  A  problem  report  has  been 
submitted  to  the  CCiTT  asking  for  clarification.  ' 

Though  there  is  not  any  statement  in  X.41 1  about  the  last  four  bits  of  the  PerMessageRag,  some  i 
vendors  have  encoded  this  with  zero  unused  bits,  and  some  have  encoded  it  with  four  unused  bits.  The 
PerMessageRag  should  be  encoded  with  at  least  four  unused  bits. 

- 

D.5     Encoding  of  empty  bitstrings 

There  are  three  valkj  encodings  for  an  empty  bitstring:  a  constructor  of  length  zero,  a  constructor  of  ! 
indefinite  length  followed  by  the  end-of-contents  terminator,  and  a  primitive  of  length  one  with  a  zero 
octet  as  the  value.  i 
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D.6     Additional  octets  for  bitstrings 

Nothing  in  X.409  constrains  an  implementation  from  sending  two,  three,  four,  or  even  more  octets  for  a 
bitstring  that  fits  into  one  octet,  with  the  undefined  bits  set  to  zero.  Note  that  the  number  of  excess 
octets  is  bounded  by  the  pragmatic  constraints  guidelines  of  the  CCiTT  X.400  impiementor's  Guide  for 
ali  of  the  bitstrings  in  PI. 


D.7     Application  protocol  identifier 

If  a  value  other  that  1  is  received  in  the  appiicationProtocol  of  the  pUserData  in  the  PConnect,  NiST 
implementations  will  reject  the  connection,  if  CEN/CENEI^C  implementations  receive  a  value  other  than 
8883  for  this  field,  they  will  reject  the  connection.  This  is  an  unfortunate  state  of  affairs,  t>ecause  if  NIST 
implementations  accept  the  value  of  8883  without  supporting  the  MOTIS  service  elements,  they  would  be 
misrepresenting  themselves.  To  make  matters  worse,  CEPT  uses  a  value  of  1 ,  but  relays  MOTIS 
elements,  which  means  that  MOTIS  elements  will  be  relayed  to  implementations  using  a  value  of  1  to 
demonstrate  that  they  do  not  support  MOTIS.  Work  is  continuing  to  try  to  find  a  solution  that  will  allow 
European  implementations  to  intenvork  with  U.S  implementations. 


D.8     Initial  serial  number  in  S-CONNECT 

This  should  be  implemented  in  accordance  with  section  3.5.1  E4  of  the  Impiementor's  GukJe. 


D.9     Connection  data  on  RTS  recovery 

It  is  clarified  that  the  ConnectionData  is  kJentlcal  in  both  the  S-CONNECT.request  and  the  S- 
CONNECT.response.  The  value  of  the  ConnectionData  is  the  old  Session  Connection  Identifier. 


D.10    Activity  resume 

If  an  activity  is  being  resumed  on  a  new  session  connection,  it  is  not  clear  from  X.410  and  X.225  whether 
all  four  of  the  called-ss-user  reference,  the  calling-ss-user  reference,  the  common  reference,  and  the 
additional  reference  information  should  be  specified  in  the  S-ACTIVITY-RESUME,  or  whether  one  of  the 
I  ss-user-references  should  be  absent.  It  is  also  unclear  whether  the  called-ss-user  reference  should  be 
I  identical  to  the  calling-ss-user  reference  if  both  are  present.  Consequently,  receivers  should  be  tolerant 
i  of  this  situation.  Appropriate  problem  reports  will  be  submitted  to  the  CCITT  asking  for  clarification. 
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D.11    Old  activity  identifier  j 

The  Old  Activity  identifier  in  S-ACTIVITY-RESUME  refers  to  the  original  activity  identifier.  j 

I 

D.I  2    Negotiation  down  to  transport  class  0 

For  European  implementations,  X.410  specifies  that  dass  0  transport  must  be  supported.  However,  it  Is 
permissit>le  for  an  initiator  to  propose  a  higher  class  as  the  preferred  class,  provided  that  dass  0  i 
appears  as  the  alternate  dass  in  the  T-Connect  PDU.  A  responding  implementation  can  choose  to  use 
either  the  preferred  or  alternate  dass,  but  again,  must  be  able  to  use  dass  0.  in  other  words,  for  private  i! 
to  private  connections  in  Europe,  dass  0  transport  is  required. 

This  conflicts  with  the  OIW  agreements,  since  dass  0  is  only  required  if  one  of  the  partners  in  a  \ 
connection  is  an  ADMD. 


i 
\ 

\ 
I 
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Annex  E  (informative)  

Worldwide  X.400  conformance  profile  matrix 

Y  CX)NFORMANCE  (E)  implies  a  confotinance  problem  for  European  products  in  the  United  States. 

Y  CX)NFORMANCE  (US)  implies  a  confomnance  problem  for  U.S.  products  in  Europe. 
The  A/31 1  profile  is  specified  in  Env  41  202,  the  A/321 1  profile  in  Env  41  201 

No  TTC  protocol  classification  for  RTS  exists. 

The  notation  X/Y  indicates  'X"  for  PRMDs  and  "Y"  for  ADMDs.  i.e.,  "M/G"  would  be  Mandatory  for 
PRMDs  and  Generatable  for  ADMDs. 


Table  E.I  -  Protocol  element  comparison  of  RTS 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  Y/N 

PConnect 

M 

M 

M 

N 

DataTremsferSyntax 

M  0 

M  0 

M  0 

N 

PUserData 

M 

M 

M 

N 

checkpointSize 

H 

H 

H 

N 

windowSize 

H 

H 

H 

N 

dialogueMode 

H 

H 

H 

N 

connect data 

M 

M 

M 

N 

applicationProtocol 

G  1 

H  1 

R  8883 

N 

H  8883 

Connect  i  onDa  t  a 

Open 

G 

G 

G 

N 

Recover 

G 

H 

G 

N 

Open 

RTSUserData 

G 

G 

G 

N 

Recover 

Sess  i  onConnec t  i  onID 

G 

G 

G 

N 

RTSUserData 

MTAName 

G 

G 

G 

N 

Password 

G 

G 

G 

N 

null 

G 

G 

G 

N 

SessionConnectionID 

CallingUserReference 

M 

M 

M 

N 

CommonRe f e r ence 

M 

M 

M 

N 

Addi  t  ionalRef Info 

H 

H 

H 

N 
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Table  E.1  •>  Protocol  oltmofit  comparison  of  RTS  (concluded) 


RTS  element 

HIST 

A/311 

A/3211 

PROBLEM  (Y/N) 

PAccept 

G 

1  ^ 

G 

N 

Dat aTr ans  fer Syntax 

M  0 

1        M  0 

M  0 

N 

PUserData 

M 

M 

M 

N 

Checkpoints! ze 

H 

B 

H 

N 

Windows ize 

H 

H 

H 

N 

Connect  i  onDa t a 

M 

M 

M 

N 

PRefuse 

6 

6 

G 

N 

RefuseReason 

M 

M 

M 

N 

SSUserData 

G 

G 

G 

N 

(in  S-TOKEN-PLEASE) 

Abort Information 

G 

G 

G 

N 

(in  S-U-ABORT) 

Abort Reason 

H 

H 

H 

N 

ref lectedParameter 

X 

X 

X 

N 

i 

•j  "  ' 


1  <  ' 

'  '  'I. 
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Table  E.2  -  Protocol  element  comparison  of  Pi 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

ORnaune 

StandardAttributeList 

M 

M 

M 

M 

N  See  Note  4 

Doma i nDe £ At t r i bu t eL i s t 

X 

X 

X 

G 

Y  See  Note  5 

StandardAttributeList 

Count  ryNcune 

R 

R 

R 

M 

N 

SO  R 

R 

N 

.  l./,x 

If 

XI 

X  ^onrormance 

ther 

X 

Y  Prot  Vio 

Adm i n i s t r a t i onDoma i nName 

R 

R 

G 

M 

N 

...  if  PrintableString 

R 

G 

N 

...  if  numericString 

H 

H 

Y  Conformance  (E) 

X.121  Address 

X 

X/R 

X 

cont(us;see  Note  i 

Terminal  ID 

X 

X/G 

X 

Conf(US)See  Note  1 

r  r  1 V  a  L  eiJonia  1  nM  ame 

c 

c 

r> 

n 

Organizati  onName 

G 

G 

G 

G 

N 

UniqueUAidentif ier 

X 

X/G 

X 

Conf(US)See  Note  1 

PersonalName 

G 

G 

G 

G 

N 

urgani za^ lonaiuni l 

fi 

Vj 

fZ 
\J 

Doma i nDe £ i nedAt t r i bu t e 

X 

X 

X 

G 

N 

Type 

M 

M 

M 

M 

N 

Value 

M 

M 

M 

M 

N 

IT  6  £  0  vjilcl  X  n  cUU6 

Surname 

M 

M 

M 

M 

N 

C  i  venName 

G 

G 

G 

G 

N 

Initials 

G 

G 

G 

G 

N 

Gene  rati  onQual i  f  i  e r 

G 

X 

X 

X 

Y  Conformance  (E) 

GlobalDomainldentif ier 

Count  ryNeune 

M 

M 

M 

M 

N 

Adm i n i s t r a t i onDoma i nName 

M 

M 

G 

M 

Y  Proto  Vio 

PrivateDomainldentif ier 

R/H 

H 

R 

M/X 

N 

MPDU 

UserMPDU 

G 

G 

G 

G 

Y  TTC  required 

MPDU  size  is 

32K 

De 1 i  ve  r yRepor  t MPDU 

G 

G 

G 

G 

N 

[  ProbeMPDU 

H 

H 

H 

H 

N 

I 
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Table  E.2  -  Protocol  element  comparison  of  PI  (continued) 


1   —  —  

PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

 — -.  — 1 

PROBLEM  (Y/NJ 

UserMPDU 

 :  :  ____  ^  ______ 

UMPDUenvelope 

M 

M 

M 

M 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

UMPDUenvelope 

MPDUidentifier 

M 

M 

M 

M 

N 

or i g i na t orORname 

M 

M 

M 

M 

N 

or  i  a  i  nalEncodedTvoes 

G 

H 

E 

Q 

Y  Conf ormancie  IK\ 

ContentType 

M 

M 

M 

M 

N 

UAcontentID 

H 

H 

H 

H 

N 

Priority 

G 

G 

G 

G 

N 

PerMessageFlag 

G 

G 

G 

G 

N 

Defer redDeli very 

X 

X 

X 

X 

N 

Pe r Doma i nB i 1 a t I nfo 

X 

X 

X 

X 

N 

Recipient Info 

M 

M 

M 

M 

Y  TTC  MPDU  32K 

Tracelnf  ormat*  inn 

M 

M 

M 

M 

M 

MOTIS->  LatestDelivery 

X 

N 

MOTIS->  InternalTracelnfo 

M/P 

P 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

MPDUidentif ier 

Globa IDoma i nident 

M 

M 

M 

M 

N 

lASstring 

M 

M 

M 

M 

N 

PerMessageFlag 

DiscloseRecipients 

H 

e  MT 

H 

1 

Y  Conformemce  (US) 

at  U 

? 

Y  Conformance  (US) 

ConversionProhibited 

G 

G 

G 

G 

N 

AlternatRecipAllowed 

H 

g  MT 

H 

X 

Y  Conformemce  (US) 

at  U 

? 

Y  Conformance  (US) 

Content Re tu rnRegues t 

X 

X 

X 

X 

MOTIS->  redirectionProhibited 

X 

N 

PerDomainBi lateralinf o 

Count  ryNeune 

M 

M 

M 

M 

N 

Adnii  nDoma  i  nName 

M 

M 

G 

M 

Y  Prot  Vio 

MOTIS->     PrivateDomai nName 

G 

N 

Bi lateralinf o 

M 

M 

M 

M 

N 
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Table  E.2  -  Protocol  element  comparison  of  Pi  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

DeliveryReportContent 

original  MPDUident 

M 

M 

M 

M 

N 

intermediate  Trace 

X/G 

X 

X 

X 

Y  Conformance  (E) 

UAcont ent ID 

G 

G 

G 

G 

N 

Repo r t edRec i p i en t I n f o 

M 

M 

M 

M 

Y  TTC  256  max 

rebUrnea 

H 

H 

X 

X 

Y  Conformance  ( E ) 

billing  information 

X 

X 

X 

X 

N 

Repor t edRec i pi ent Info 

recipient  ORname 

M 

M 

M 

M 

N 

excens ions laent icier 

M 

M 

M 

M 

N 

PerRecipientFlag 

M 

M 

M 

M 

LastTracelnformation 

M 

M 

M 

M 

N 

i  nt  endedRec  i  pi  ent 

H 

H 

H 

H 

N 

Supplementary Info 

X/H 

X 

X 

X 

Y  Conformance  (E) 

MOTIS-> 

Reas s i gnment Inf o 

X 

N 

If /^m  T  c  *v 
MOTlo— > 

Reass ignment Inf o 

U/MTI  TO  ^ 

MOT I 5— > 

i  nt  endedRec  i  p  i  ent 

M 

N 

MUTlO— ^ 

reasonr  orKeass i gnmenr 

H 

N 

Las tTraceInf ormat  ion 

arrival 

M 

M 

M 

M 

N 

con  ve  r  c  eacinc  i  n  r  oxypes 

G 

G 

H 

G 

Y  Conformance  (E) 

Report 

M 

M 

M 

M 

N 

Report 

Deliveredlnfo 

G 

G 

G 

> 

N  see  Note  o 

NonDeliveredlnfo 

G 

G 

G 

N 

Deliveredlnfo 

delivery 

M 

M 

M 

M 

N 

TypeofUA 

R/H 

H 

R 

M/G 

N 

NonDeliveredlnfo 

ReasonCode 

M 

M 

M 

M 

N 

Diagnosti  cCode 

H 

H 

H 

H 

N 

MOTIS-> 

UAprof ileldentif ier 

X 

N 

MOTIS-> 

UAprof ileldentif ier 

MOTIS-> 

ContentType 

M 

N 

MOTIS-> 

Encoded I nf oTypes 

M 

N 
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Table  E.2  -  Protocol  elomont  comparison  of  Pi  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

ProbeEnvelope 

probe 

M 

N 

M 

M 

N 

originator 

M 

M 

M 

M 

N 

Content Type 

M 

M 

M 

M 

N 

UAcontentID 

H 

H 

H 

H 

N 

originalEncInfoTypes 

6 

H 

H 

G 

Y  Conformemce  (E) 

Tracelnformation 

M 

M 

M 

M 

N 

Pe r Me s s ageF 1 ag 

G 

G 

G 

G 

N 

ContentLength 

H 

H 

H 

H 

N 

PerDomainBilatlnfo 

X 

X 

X 

X 

N 

Recipient Info 

M 

M 

M 

M 

Y  TTC  256  max 

MOTIS->  InternalTracelnfo 

M/P 

P 

N 

Recipient Info 

Kec  1  p  1 8n  kUKnaine 

n 

n 

w 

n 

N 

N 

Extens ionldent i f ier 

M 

M 

M 

M 

N 

PerRecipientFlag 

M 

M 

M 

M 

N 

Expl i c i t Conve r s i on 

X 

X 

X 

X 

N 

MOTIS->  OriginReqAlternatRecip 

X 

N 

MOTIS->     Reassignment Info 

X 

N 

PerRecipientFlag 

Respons  ibi 1 i  tyFlag 

M 

M 

M 

M 

N 

ReportRequest 

M 

M 

M 

M 

N 

UserReportRequest 

M 

M 

M 

M 

N 

Tracelnformation 

GlobalDomainldent 

M 

M 

M 

M 

N 

DomainSuppliedlnfo 

M 

M 

M 

M 

N 
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Table  E.2  -  Protocol  element  comparison  of  Pi  (concluded) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

Doma i nSuppl i ed I nf o 

arc  i vsl 

M 

M 

M 

M 

N 

deferred 

X 

X 

X 

X 

N 

action 

M 

M 

M 

M 

N 

(O^relayed) 

G 

G 

G 

N  Note: 

Re-routing  not 

required. 

H 

H 

H 

N 

MOTIS->  (2=recipientReassigned) 

H 

N 

converted 

H 

G 

H 

H 

Y  Conformance (US) 

previous 

H 

G 

G 

X 

Y  Conformance (US) 

(Note:  G  is 

inconsistent  with 

action  (relayed) 

being  "H.") 

ORname 

Encodedlnformat i onTypes 

BitString 

M 

M 

M 

M 

N    See  Note  3 

G3NonBas i cPa r ame t e r s 

X 

X 

X 

X 

N 

TeletexNonBas icParams 

X 

R 

X 

X 

Y  Conformance (US) 

PresentationAbilities 

X 

X 

X 

X 

N 

DeliveryReportMPDU 

G 

G 

M 

G 

N 

Del i veryRepor tEnvelop 

M 

M 

M 

M 

N 

Del i veryRepor tCont ent 

M 

M 

M 

M 

N 

DeliveryReportEnvelope 

report 

M 

M 

M 

M 

N 

originator  ORname 

M 

M 

M 

M 

N 

Tracelnformation 

M 

M 

M 

M 

N 

InternalTracelnfo 

M/P 

P 

N 
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Table  E.3  -  Protocol  element  comparison  of  P2 


P2  Protocol 

 — _____  ,  ______ 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

UAPDU 

IM  UAPDU 

6 

G 

G 

G 

N 

SR_UAPDU 

X 

X 

X 

X 

N 

IM_UAPDU 

Heading 

M 

M 

M 

M 

N 

Body 

M 

M 

M 

M 

N 

Heading 

IPmessagelD 

M 

M 

M 

M 

N 

Originator  ORname 

R 

R 

R 

M/G 

N 

Author  i  z  ingUsers 

V* 

n 

H 

H 

H 

Y  TTC  Id  max 

Pr  imaryRec  i  pi  ent  s 

G 

G 

G 

G 

Y  TTC  256  max 

CopyRec i p i en t s 

G 

G 

G 

G 

Y  TTC  256  max 

Bl i ndCopyRec i pi ent 

H 

H 

H 

H 

Y  TTC  256  max 

InReplyTo 

G 

G 

G 

G 

N 

Obsoletes 

H 

H 

H 

H 

Y  TTC  8  max 

CrossReferences 

H 

H 

H 

H 

Y  TTC  8  max 

Subject 

G 

G 

G 

G 

N 

ExpiryDate 

H 

H 

H 

H 

N 

ReplyBy 

H 

H 

H 

H 

N 

Rep 1 y ToUs  e  r  s 

n 

H 

n 

H 

Y  TTC  32  max 

Importance 

H 

H 

H 

H 

N 

Sensitivity 

H 

H 

H 

H 

N 

Autoforwarded 

H 

H 

H 

H 

N 

MOTIS->  CirculationList 

X 

N 

MOTIS->  ObsoletingTime 

X 

IPmessagelD 

ORname 

H 

H 

H 

H 

N 

PrintableString 

M 

M 

M 

M 

N 

ORdescriptor 

ORname 

H 

H 

H 

> 

N  See  Note  6 

FreeFormN£une 

H 

H 

H 

N 

Tel ephoneNumbe  r 

H 

H 

H 

G 

N 

Recipient 

ORdescriptor 

M 

M 

M 

M 

N 

ReportReguest 

X 

X 

X 

X 

N 

ReplyRequest 

H 

H 

H 

H 

N 
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Table  E.3  -  Protocol  element  comparison  of  P2  (continued) 


P2  Protocol 

NI8T 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

MOTIS->  CicculatloiiList 

NOTIS— >  circui&tionneiMDer 

X 

N 

MOTIS—>  cnecKinark 

N 

M 

N 

MOTlS->  ■enbernaaie 

n 

N 

MOTIS->  OBsoletingTime 

MOTIS->  Tiae 

H 

N 

m<Alff1TC!    ^           TB    Mama  amaTA 

H 

N 

Body 

BodyPart 

G 

n 

M 

G 

Y  Conformance  (US) 

SR_UAPDu 

NonReceipt 

*• 

H 

«• 
n 

«• 

n 

N 

Receipt 

H 

H 

H 

J-M 

N 

Reported 

M 

M 

N 

M 

N 

ActualRecipient 

R 

R 

R 

(ar 

N 

I n t enaedRec i p i en t 

n 

It 
H 

H 

It 
H 

N 

uonvercea 

V 
A 

V 
A 

V 
A 

f 
\a 

N 

MOTlS->  CirculationStatus 

X 

N 

NonReceipt Infornat ion 

Reason 

M 

M 

M 

M 

N 

NonRece  iptQual i  £  i  er 

H 

H 

H 

H 

N 

^expired  (value) 

0 

0 

0 

0 

N 

sobsoleted  (value) 

1 

1 

1 

1 

N 

-subscript ionTerninated 

2 

2 

2 

2 

N 

MOTlS->     =timeobsoleted  (value) 

X 

N 

Comments 

H 

H 

H 

X 

N 

returned 

H 

X 

X 

X 

Y  Conformance  (E) 

Receiptlnformation 

Receipt 

M 

M 

M 

M 

N 

TypeOfReceipt 

H 

H 

H 

G 

N 

Supplementarylnfo 

X 

X 

X 

X 

N 

1 
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Table  E.3  -  Protocol  element  comparison  of  P2  (conduded) 


P2  Protocol 

MIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

BODYPART  SUPPORT 

o  IA5  Text 

G 

6 

G 

N  See  Note  7 

O  TLX 

X 

X 

X 

N 

o  Voice 

X 

X 

X 

N 

o  G3FAX 

X 

X 

X 

N 

O  TIFO 

X 

X 

X 

N 

o  TTX 

X 

X/H 

X 

Y  Conf (US)See  Note  2 

o  VideoTex 

X 

X 

X 

N 

o  NationallyDefined 

X 

X 

X 

N 

o  Encrypted 

X 

X 

X 

N 

o  ForwardedlPmessage 

H 

H 

H 

N 

o  SFD 

X 

X 

X 

N 

o  TIFI 

X 

X 

X 

N 

MOTIS->  O  ODA 

X 

N 

MOTIS->  o  IS06937  Text 

H 

N 

NOTES 

1  It  should  be  noted  that  the  A/31 1  profile  states:  For  routing  all  ADMDs  should  support  all  Form  1 
Variants  of  0/R  Name.  All  PRMDs  should  support  at  least  Form  1 ,  Variant  1  form  of  OR  Name. 

2  It  should  also  be  noted  that  the  A/31 1  profile  requires  that  all  ADMDs  should  support  the  reception  of 
Teletex  body  parts  for  delivery  to  their  own  UAEs. 

3  An  A/3211  implementation  may  generate  MOTIS  encoded  information  types.  See  6.11. 

4  Only  Form  1  Variant  1  of  0/Rname  shown  for  TTC,  but  TTC  defines  other  forms  and  variants.  Form  1 
Variant  1  recommended  for  PRMDs  and  ADMDs,  Form  1  Variant  2  also  recommended  for  ADMDs. 

5  DDA's  can  be  used  to  specify  recipients  in  any  Japanese  domains  other  than  TTC.  Assignment  of  DDAs 
for  UAs  within  TTC  domains  is  not  recommended. 

6  One  of  [Deliveredlnfo/NonDeliveredlnfo]  must  be  present.  TTC  encodes  this  as  shown.  Other  profiles 
represent  this  by  classifying  both  protocol  elements  as  generatable.  A  similar  situation  exists  with  the  P2 
ORdescriptor. 

7  TTC  is  expected  to  support  IA5  for  some  international  MHS  communications. 
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Annex  F  (informative)  

Interworking  warnings 

ADMD  name  is  to  be  encoded  as  a  single  space  when  configurations  with  no  ADMD's  are  present.  It 
should  be  noted  that  this  niay  change  in  January  1988  so  that  the  ADMD  name  is  encoded  as  a  zero 
length  element  in  such  cases. 

The  OSI  Implementors'  agreements  allow  implementation  to  generate  MPDUs  with  no  txxly  parts.  Such 
MPDUs  will  be  rejected  by  European-conformant  systems.  (Note  this  situation  may  change  in  January 
1988) 

In  order  to  optimize  the  number  of  recipients  you  can  read  and  reply  to,  it  is  advisable  to  be  able  to 
generate  all  standard  0/R  name  attributes. 
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Foreword 

The  text  in  this  part  contains  a  set  of  Message  Handling  System  (MHS)  Implementation  Agreements 
intended  to  serve  in  lieu  of  an  International  Standardized  Profile  (ISP)  for  MHS.  It  is  the  aim  of  the  OIW 
X.400  SIG  to  pursue  alignment  of  this  part  with  the  developing  ISP.  When  the  ISP  is  complete,  this  part 
will  be  revised  to  refer  to  the  ISP,  and  to  only  highlight  additional  practices  and  North  American  regional 
requirements. 
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Part  8  Message  Handling  Systems 


0  Introduction 

This  is  an  Implementation  Agreement  developed  by  the  Implementors'  Workshop  sponsored  by  the  National 
Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufectured  by  different  vendors.  This  Agreement  is  based  on,  and  employs  protocols  developed  in  accord 
with,  the  OSI  Reference  Model.  It  provides  detailed  guidance  for  the  implementor  and  eliminates  ambiguities 
In  interpretations. 

This  is  an  implementation  Agreement  for  Message  IHandling  Systems  (MHS)  based  on  the  CCITT  X.400 
(1988)  series  of  Recommendations,  the  similar  (but  not  identical)  ISO  MOTIS  standard,  and 
j  Recommendations  F.435  and  X.435  (1991)  (see  References).  These  Recommendations  and  Standards  are 

1  refen'ed  to  as  the  base  standards.  The  term  "MHS"  Is  used  to  refer  to  tx)th  sources  where  a  distinction  is 
I  unnecessary.  Similarly,  "1984"  and  "1988"  are  often  used  to  distinguish  between  the  CCITT  X.400  (1984) 
series  of  Recommendations  and  the  later  sources. 

This  implementation  Agreement  seel<s  to  establish  a  common  specification  which  is  conformant  with  both 
j  CCITT  and  ISO  with  a  view  to: 

I  a)  Preventing  a  proliferation  of  incompatible  communities  of  Ml-iS  systems  which  are  isolated  for 

protocol  reasons: 

b)  Achieving  interworking  with  implementations  conforming  to  the  01 W  Stable  Implementation 
Agreements  for  CCITT  1984  X.400-t)ased  Message  Handling  Systems;  and, 

I  c)  Facilitating  integration  of  other  OSI-based  services  (e.g..  Directory)  within  a  single  real  system. 

This  implementation  Agreement  is  designed  to  encourage  upgrade  of  existing  1984-based  systems  as 
1  follows: 


a)  To  add  1988  functionality  (Message  Store,  Remote  User  Agent,  etc.); 

b)  To  provkJe  additional  functionality  above  the  minimal  conformant  1988  MHS  defined  in  the 
December  1989  version  of  the  OIW  Implementation  Agreements.  These  1988  aspects  are  described 
in  this  Agreement  as  either  incremental  enhancements  or  new  functional  groups. 


:  However,  it  is  considered  that  the  OIW  Stable  Implementation  Agreements  for  CCITT  1984  X.400-based 
Message  Handling  Systems  (part  7)  should  not  be  withdrawn  at  this  stage.  It  is  anticipated  that  X.400  (1984) 
Implementations  will  continue  to  provide  a  viable  alternative  for  applications  that  do  not  require  the  additional 

;  1988  functionality  for  some  time. 
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1  Scope 

This  Agreement  specifies  tlie  requirements  for  Ml-iS  implementations  based  on  tlie  1988  MHS  standards. 

This  Agreement  applies  equally  to  Private  Management  Domains  (PRMDs)  and  Administration  Managenwnt 
Domains  (ADMDs).  Four  boundary  interfaces  are  specified,  as  illustrated  in  figure  1: 

a)  Management  Domain  (MD)  to  MD; 

b)  Message  Transfer  Agent  (MTA)  to  MTA  within  a  domain; 

c)  MTA  to  remote  Message  Store  (MS)  or  User  Agent  (UA);  and, 

d)  MS  to  Remote  UA. 

MHS  protocols  other  than  the  Message  Transfer  Protocol  (PI),  the  Message  Transfer  System  Access 
Protocol  (P3),  the  Interpersonal  Messaging  Protocol  (P2),  and  the  Message  Store  Access  Protocol  (P7)  are 
beyond  the  scope  of  this  Agreement.  Issues  arising  from  the  use  of  other  protocols  are  outside  the  scope 
of  this  document.  This  Agreement  describes  the  services  provided  at  each  interface  shown  in  figure  1 . 

MHS  implementations  may  be  configured  as  any  single  or  multiple  occurrence  or  combination  of  MTA.  MS 
and  UA,  as  illustrated  in  figure  1 .  It  is  not  intended  to  restrict  the  types  of  system  that  may  be  configured 
for  conformance  to  this  Agreement  (although  it  is  equally  recognized  that  not  all  configuration  types  may 
be  commercially  viable). 


MD 


UA 


MTA 


UA 


MS 


MTA 


PI 


PI 


PI 


P3 


MTA 


MTA 


MS 


UA 


P3 


MS 


P3 


MS 


P7 


P7 


UA 


UA 


Figure  1  -  Scenario  definition 

The  1988  MHS  standards  cover  a  wide  and  diverse  range  of  functional  areas,  not  all  of  which  would  be 
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relevant  to  every  implementation,  in  order  to  achieve  a  more  precise  definition  of  conformance  requirements 
according  to  the  functionality  supported  by  an  implementation,  and  additionally  to  facilitate  future 
enhancement  of  this  initial  specification,  the  concept  of  Functional  Groups  has  l>een  Introduced. 
Conformance  requirements  for  support  of  Functional  Groups  by  particular  configurations  are  specified  in 
clause  17. 

In  the  context  of  these  agreements,  the  term  "Support"  means  that  the  service  provider  mal<es  the  element 
of  service  (and  related  elements  of  protocol)  avallat)le  to  the  service  user.  The  service  user  provides 
adequate  access  to  invoke  the  elements  of  service  and/or  makes  information  associated  with  the  servk^e 
element  available.  Additionally,  for  "Not  Defined'  or  "Not  Applicable"  elements,  the  sen/tee  provider  is  not 
required  to  make  the  element  available  to  the  servtee  user.  However,  the  servtee  provider  shoukl  not  regard 
the  occun^ence  of  the  corresponding  protocol  elements  as  an  en'or  and  should  relay  those  elements. 
Naturally,  protocol  elements  marked  critical  for  submisskm,  transfer,  or  delivery  must  be  processed 
according  to  the  base  standards. 

The  following  functional  groups  are  covered  by  this  Implementors  Agreement: 

a)  The  MT  Kemei  in  clause  5; 

b)  The  Message  Store  in  clause  6; 

c)  Remote  User  Agent  support  in  clause  7; 

d)  DistributkHi  Lists  in  clause  8.3; 

e)  Use  of  Directory  in  clause  8.4; 

f)  Address  support  for  Teletex  character  sets  in  clause  8.5; 

g)  MHS  Management  in  clause  9  (which  is  for  further  study); 

h)  Security  in  clause  10; 

i)  The  Physical  Delivery  Access  Unit  in  clause  11.1; 

j)  Other  Access  Units  in  clause  1 1.2  (which  are  for  further  study); 
k)  Redirection  in  clause  12  (which  Is  for  further  study);  and, 
I)  The  IPM  Service  in  clause  13; 

m)  The  EDI  Messaging  Service  In  clause  14  (which  is  for  further  study). 
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2.1  CCITT 

Application  Layer  -  MHS 

CCITT  Recommendation  X.400  (1988),  Message  Handling,  System  and  Service  Overview. 

CCITT  Recommendation  X.402  (1988),  Message  Handling  Systems,  Overall  Architecture. 

CCITT  Recommendation  X.407  (1 988) ,  Message  HarKliing  Systems,  Abstract  Sen/ice  Definition  Conventions. 

CCITT  Recommendation  X.411  (1988),  Message  Handling  Systems,  Message  Transfer  System:  Abstract 
Service  Definition  and  Procedures. 

CCITT  Recommendation  X.413  (1988),  Message  Handling  Systems,  Message  Store:  Abstract  Sen/ice 
Definition. 

CCITT  Recommendation  X.419  (1988),  Message  Handling  Systems,  Protocol  Specifications. 

CCITT  Recommendation  X.420  (1988),  Message  Handling  Systems,  Interpersonal  Messaging  System. 

CCITT  Recommendation  X.I 21  (1988),  International  Numbering  Plan. 

CCITT  Recommendation  X.435  (1991),  Message  Handling  Systems,  EDI  Messaging  System,  Protocol 

Specifications. 

CCITT  Recommendation  F.435  (1991),  Message  Handling  Systems,  EDI  Messaging  System,  Abstract  Sen/ice 
Definition. 


2.2  ISO 

Application  Layer  •  MHS 

ISO  10021-1  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  System  and  Service 
Overview. 

ISO  10021-2  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Overall  Architecture. 

ISO  10021-3  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Abstract  Service  Definition 
Conventions. 

ISO  10021-4  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Message  Transfer  System: 
Abstract  Sen/ice  Definition  and  Procedures. 

ISO  10021-5  Information  Processing  Systems  ~  Text  Communication  -  MOTIS  -  Message  Store:  Abstract 
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Service  Definition. 

ISO  10021-6  Information  Processing  Systems  -  Text  Communication  -  MOTiS  -  Protocol  Specifications. 

ISO  10021-7  Information  Processing  Systems  -  Text  Communication  •  MOTiS  -  Interpersonal  Messaging 
System. 


3  Status 

'  This  version  of  the  Implementation  Agreements  for  Message  Handling  Systems  (MHS)  is  under  development. 
I  it  Is  based  on  the  CCITT  X.400  (1988)  Recommendations  and  ISO  MOTiS  (10021,  parts  1-7)  standards,  as 
|{  amended  by  the  MHS  Implementors  Guide,  version  6. 

I  The  initial  versbn  of  these  Stable  Implementation  Agreements  included  an  Agreement  which  specified  a 
I  minimal  1988-based  MHS  implementation  and  support  for  Message  Stores  and  Remote  User  Agents,  and 
i  which  addresses  Inten^vorking  with  1984-based  implementations.  This  version  of  the  Agreement  specifies 
support  for  several  additional  1988  features.  The  remaining  features  specified  in  the  1988  (.standards  wHI  be 
I  covered  in  subsequent  versions  of  this  Agreement, 
i 

i  This  initial  version  has  not  yet  been  aligned  with  other  MHS  profiles,  so  changes  may  be  necessary  in  the 
future  for  international  harmonization,  e.g..  support  for  international  character  repertoires  and  conversion. 


i  4  Errata 

No  Errata  to  Stable  material  at  this  time. 

5    MT  kernel 
5.1  Introduction 

j  This  clause  specifies  the  requirements  for  a  minimal  1988-based  MTS  implementation  (i.e.,  MTA)  which  is 
capable  of  intenA^orking  with  1984-based  MTAs.  The  "base'  MT  Service  specified  in  this  clause  does  not 
include: 

a)  Message  Store  (see  clause  6); 

b)  Remote  UA  (see  clause  7); 

c)  Distribution  Lists  (see  clause  8.3); 

d)  Use  of  Directory  Services  (see  clause  8.4); 

e)  Security  (see  clause  10); 
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Q  Interworking  with  Physical  Delivery  systems  or  Specialized  Access  (see  clause  11);  and, 

g)  Conversion  of  body  parts  (see  dausa  13.6.2). 

Such  a  minimal  1988-based  MTA  wMI  have  the  following  capafc>lities  in  order  to  achieve  interworldng  with 
1984-ba8ed  MTAs  and  to  facSitate  migration  to  fun  1968  operation: 

a)  It  wll  t)e  protocol-conformant  to  1966  PI ; 

b)  It  wW  downgrade  1968  PI  to  1964  PI  when  relaying  to  1964-based  MTAs,  as  specified  in  Annex 
B  of  X419  (see  clause  5.5); 

c)  It  wit  support  both  'normal'  mode  and  'X.410-1964'  Cpassthrough")  mode  protocol  stacks  (l  e., 
as  required  by  ISO  and  CCITT  resf)ectively);  and, 

d)  A  coriformingimplernentatk>nsliall  obey  tiiecritteality  mechanism  defined  in  the  t>ase  standards. 
The  following  abstract  operatkMis  are  made  crittoal  for  delivery  for  these  Implementatkm 
Agreements:  message  token,  content  integrity  check,  and  content  confkjentiality  algorithm  Id. 


5.2     Elements  of  service 

This  dause  s()ecifles  the  requirements  for  support  of  MT  Elements  of  Servk^e  by  an  MTA  conforming  to  the 
MT  Kernel  FurK:tk>nal  Group  of  this  Agreement.  Table  1  s()ecifies  tfie  sujaport  for  the  t>ask;  MT  Kernel 
elements  of  servk^e  and  table  2  specifies  the  sujsfxxt  for  tfie  optkxial  MT  Kernel  elements  of  servk^. 

The  dassificatkMi  sciieme  for  support  of  Elements  of  Servtee  is  as  follows: 

Mandatory  (M):  the  Element  of  Servtee  must  t>e  supported  and  made  availat)le  to  tfte  servtee  user; 

Optional  (O):  the  Element  of  Servk:e  may  be  sup|x>rted,  txit  is  not  required  for  conformance  to  this 
Agreement; 

Out  of  Scope  (I):  the  Element  of  Servk^e  is  outskie  tfie  scope  of  these  lmplementatk>n  Agreements; 

Not  Applicable  (-):  the  Element  of  Service  is  not  applteable  in  the  parttoular  context  according  to 
the  base  standard;  and. 

To  Be  Detennined  (*):  the  support  classifk;atk>n  for  the  Element  of  Sen^  has  yet  to  be 
determined. 

The  requirements  for  support  of  MT  Elements  of  Service  for  origination  and  receptton  and  (where  relevant) 
relaying  are  distinguished.  Elements  of  Servtee  whteh  are  new  in  the  1968  MHS  standards  are  indk^ated  as 
(1968). 

An  MTA  must  support  those  Bask:  MT  Elements  of  Servk:e  and  MT  Optkxial  User  Facilities  defined  in  section 
19  of  X400  (1988)  as  listed  and  qualified  in  tables  1  and  2. 

Specificatk>n  of  dynamk;  behavtor  in  these  agreements  wHI  oNy  be  included  in  those  cases  where  there  is 
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|an  identified  functional  objective  whlcfi  is  not  satisfied  by  the  specification  of  dynamic  t>ehavior  in  the 
Icon-esponding  base  standard(s)  and  where  the  resulting  behavior  does  not  breach  base  standard 
|Confonnance  requirements. 

]ln  these  exceptional  cases,  there  may  be  situations  where  these  agreements  must  specify  the  dynamic 
behavior  of  an  implementation  as  distinguished  in  annex  C  of  ISO  TR-10  000.  Where  this  occurs,  a  table  of 
dynamic  conformance  requirements  will  be  presented  using  the  classification  scheme  below: 

Mandatory  (M):  The  element  must  be  implemented  although  use  is  not  required  for  conformance 
I         to  the  base  standard.  The  element  shall  always  be  used  for  conformance  to  these  agreements. 

Excluded  (X):  This  element  must  either  not  be  implemented,  or  It  must  be  possible  to  prevent  use 
of  the  element. 


NOTE  -  As  stated  in  clause  6.7  of  ISO  TR-10  000-1,  restrictions  by  a  profile  on  the  dynamic  conformance 
requirements  of  a  base  standard  are  exceptions,  and  should  only  apply  to  transmission.  Restrictions  should 
not  apply  to  reception.  In  the  case  of  Excluded  options,  it  must  be  possible  to  ensure  that  such  options  are 
not  Initiated  or  transmitted.  However,  it  is  still  possible  that  an  implementation  may  receive  an  Excluded  element 
from  an  implementation  which  does  not  conform  to  the  same  profile. 

Table  1  -  MT  kernel:  basic  MT  elements  of  service 


Element  of  Service 

Origination 

Reception 

Relaying 

Access  Management 

Ml 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

M 

M 

Delivery  Time  Stamp  Indication 

M 

Message  Identification 

M 

M 

Non-delivery  Notification 

M 

M 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  Steunp  Indication 

M 

M 

User/UA  Capabilities 

Registration  (1988) 

Ml 

Notes 

1    A  local  matter  in  the  case  of  collocated  UA/MTA  and/ov 
MS/MTA  configurations. 

I 

i 

I 
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Table  2  -  MT  kernel:  MT  service  optional  user  faciltties 


Element  of  Service 

Origination 

Kecepc ion 

Kexaying 

Alternate  Recipient  Allowed 

M 

Alternate  Recipient  Assignment 

u 

Conversion  Prohibition 

n 

n 

u 

n 

Conversion  Prohibition  in  Case 

o£  Loss  of  Information  (1988) 

u 

r\ 
U 

Deferred  Delivery 

m3 

0 

U 

Deferred  Delivery  Cancellation 

M^ 

~ 

Delivery  Notification 

M 

N 

Disclosure  of  Other  Recipients 

M 

n 

DL  Expansion  History  Indication 

n 

DL  Expansion  Prohibited 

w5 
M 

Explicit  Conversion 

0 

0 

r\ 
Q 

Grade  of  Delivery  Selection 

N 

u 

n 

Hold  for  Delivery 

M 

Implicit  Conversion 

0 

0 

0 

Latest  Delivery  Designation  (1988 

0 

0 

0 

Multi  Destination  Delivery 

M 

M 

H 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

0 

Prevention  of  Non-delivery 

Notification 

M 

Probe 

M 

M 

M 

Redirection  Disallowed  by 

Originator  (1988) 

M 

M 

Redirection  of  Incoming 

Messages  (1988) 

0 

Requested  Delivery  Method  (1988) 

M 

M 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

0 

0 

Notes 

1  A  local  matter  in  the  case  of  collocated  UA/MTA  and/or 
MS/MTA  configurations. 

2  If  Alternate  Recipient  Assignment  is  supported  on 
reception,  then  support  of  Alternate  Recipient  Allowed  is 
Mandatory  on  reception;  otherwise,  support  of  Alternate 
Recipient  Allowed  is  not  applicable  on  reception. 

3  Support  of  this  MT  Element  of  Service  is  Mandatory  for 
conformance  reasons,  but  may  be  performed  as  a  local 
matter  to  the  originating  MTA. 

4  Support  of  this  MT  Element  of  Service  refers  only  to  the 
delivery  of  DL  expansion  history  and  not  to  the  performing 
of  DL  expansion  (see  clause  8.3). 

5  Support  of  this  MT  Element  of  Service  does  not  imply  the 
capability  to  perform  DL  expansion  (see  clause  8.3). 

6  Messages  should  be  held  in  the  originating  MTA  to  provide 
support  for  this  element  of  service. 
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5.3     MTS  transfer  protocol  (PI) 

The  requirements  for  support  (rf  MTS  Transfer  Protocol  (PI)  elements  are  detailed  In  clause  A.I. 
Support  of  MTS  Transfer  Protocol  application  contexts  by  an  MTA  Is  classified  as  in  tatsle  3. 

Table  3  -  Application  contexts  classification 


Application  Context 

Support 

mt  s-t  r ans  £er-protocol~l 9  84 
mt  s- 1  r ans  fer-protocol 
mts-transfer 

Meuidatory 
Mandatory 
Mandatory 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  15. 

5.4  MTS  -  APDU  size 

This  clause  Is  not  intended  to  constrain  the  size  of  PDUs  that  are  transferred  across  the  network,  since  some 
body  part  types  and  content  types  (e.g.,  voice,  file  transfer,  and  EDI)  may  require  very  large  PDUs. 

The  following  agreements  govern  the  size  of  MTS-APDUs: 

a)  All  MTAEs  must  support  at  least  one  MTS-APDU  of  at  least  two  megabytes;  and, 

b)  The  size  of  the  largest  MTS-APDU  content  supported  by  a  UAE  is  a  local  matter. 

5.4.1       Number  of  recipient  names 

There  is  no  specified  tx>und  on  the  number  of  recipient-names  an  implementation  must  support,  other  than 
the  32K-1  specified  in  the  standard  (Annex  B/X.411). 

5.5  1988/84  interworking  considerations 

An  MTA  confomiing  to  this  Agreement  will  downgrade  1988  PI  to  1984  PI  when  relaying  to  1984-based 
MTAs,  as  specified  in  Annex  B  of  X.419  with  the  following  additional  requirements: 

a)  Supplementary  Information  -  will  need  to  be  truncated  if  it  exceeds  the  pragmatic  constraint 
Identified  In  Version  2  of  these  Agreements  (64  octets  as  opposed  to  256  octets  in  the  1988  MHS 
standards); 

b)  ISO  DIS  8883  Extensions  -  An  implementation  may  perform  the  mapping  of  ISO  DIS  8883 
extensions  to  existing  1988  services  when  relevant,  but  is  not  obliged  to.  Altematively,  It  may  discard 
the  extensions  or  generate  a  non-delivery  report; 
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c)  Internal  Trace  Information  -  If  the  1984-based  MTA  does  not  support  Internal  Trace  Information 
per  clause  7.3.2  of  part  7,  the  following  description  Is  not  applicable.  When  a  1988-based  MTA 
supports  IntenA/orking  with  a  1984-based  MTA  that  generates  Internal  Trace  Infomnation  as  per 
clause  7.3.3  of  part  7,  the  1988-based  MTA  must  support  reception  of  the  Internal  Trace  Infomiation 
by  converting  the  Internal  Trace  Information  from  the  form  in  clause  7.3.2  of  part  7  to  the  form 
specified  in  1 988  X.41 1 ,  as  per  the  following  description.  When  the  1 988-based  MTA  sends  to  a  1 984 
MTA,  the  1988-based  MTA  must  apply  the  conversion  to  1984,  as  described  below.  The  Stable  NBS 
Implementation  Agreements  X.400  (1984)  definition  for  MTA's  Internal  Trace  Information  is  different 
from  the  X.400  (1988)  MTA  definition.  Consequently,  a  X.400  (1988)  MTA  operating  in  an  MD  with 
other  MTAs  of  1984  vintage,  must  map  the  Internal  Trace  Information  to  and/or  from  the  1984 
format. 

Figures  2  and  3  depict  algorithms  for  mapping  between  X.400  (1988)  Internal  Trace  element  formats  and 
the  OIW  lA  X.400  (1984)  Internal  Trace  element  format. 

To  avoid  potential  looping  within  a  MD  composed  of  1984  and  1988  vintage  MTAs,  MD  administrators  are 
strongly  advised  to  name  all  MTAs  (1984  and  1988  vintages)  using  only  the  Printable  String  characters.  In 
X.400  (1988)  the  MTA-Name  is  defined  to  be  named  using  IA5  String  chiaracters  where  in  the  lAs  for  X.400 
(1984)  MTAs,  NBS  restricted  the  MTA-Name  to  be  formed  using  the  Printable  String  character  subset  of  IA5. 
If  the  1988-based  MTA  Name  uses  IA5  characters  not  in  the  Printat>le  String  subset,  that  Internal  Trace  j 
Element  should  be  omitted  when  converting  from  1988  to  1984. 


For  each  Internal  Trace  element  in  the  sec[uence: 
DO 

IF  MTA-Ncune  is  made  up  of  non-Printable  String  characters: 

Discard  this  Internal  Trace  element; 
ELSE 

(    Discard  the  GlobalDomainldentif ier ; 
Copy  the  MTAneune  over; 
Within  the  MTASuppliedlnformation: 


Copy  the  arrival  time  over; 
Copy  the  routing  action  over; 
IF  attempted  is  present 
{    IF  it  is  a  domain: 
Discard  it; 
IF  it  is  an  MTA: 
^       Copy  it  to  Previous  MTANeune; 

IF  the  additional  actions  are  present: 
{    IF  the  deferred  time  is  present: 
Copy  it  over; 
IF  the  other-actions  is  present: 
Discard  it; 


} 


) 


END-DO 


Figure  2  -  1988  to  1984  mapping 
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Find  the  [APPLICATION  30]  entry  in  the  PI  envelope; 
FOR  each  Internal  Trace  eleaent: 
DO 

Insert  the  GlobalDoaainldentifier  of  this  MTA; 
Copy  the  MTANaae  over; 
Within  the  NTASuppliedlnfot 
Copy  the  arrival  tiae; 
IF  the  deferred  tiae  is  present: 
copy  it  to  the  additional  actions  field  within  the 
1988  Internal  Trace  inforaation; 
IF  the  routing  action  is  Relayed  or  Rerouted: 

copy  it  over; 
IF  the  routing  action  is  Recipient-reassigned: 

aap  to  Relayed; 
IF  the  previous  MTANaae  is  present: 
copy  it  to  the  MTANaae  in  the  atteapted  field; 

END-DO 


Figura  3  - 1084  to  1988  mapping 


NOTE  -  The  1968  X.419  Reoommandatlon  acknowledge*  that  a  1984  tystem  may  reoaive  masaagaa 

containing  new  distinguished  [integer]  values  that  it  is  not  expecting,  and  that  this  may  result  in  service 
irregularities,  h  is  implied  that  it  would  tMoptirnal  for  1984  systenw  to  accept  these  unexpected  integer  vtfu^ 
if  at  all  possible.  No  downgrading  should  be  done  for  these  values  when  passing  affected  messages  from 
newer  systems  to  older  systems. 


6    Message  store 


16.1  Introduction 

This  dause  specifies  Agreements  for  implementation  of  the  Message  Store  (MS)  Functional  Group.  The  MS 
lis  responsit)le  for  accepting  delivery  of  messages  on  t)ehaif  of  a  single  end-user,  and  retaining  the  messages 
luntl  the  erxi-user's  UA  is  atiie  to  retrieve  them.  Message  sutxnission  arxl  some  administration  services  are 
provided  via  'pass-through'  to  the  MTS.  Figure  4  Wustrates  the  logical  relationship  of  the  MS  to  the  UA  and 

^MTS. 


OA 

RETRIEVAL 

MS 

DELIVERY 

MT8 

<  

INDIRECT 
SUBMISSION 

<  

SUBMISSION 



ADMINISTRATION 

<  >- 



ADMINISTRATION 
<  

Figure  4  •  Message  store  model 

IThe  Agreements  in  this  clause  specify  the  Message  Store's  use  of  the  retrieval,  delivery,  and  administration 

i 
i 
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services.  Agreements  on  submission  services  are  specified  in  clause  7,  whicli  describes  support  for  the 
Remote  UA. 

The  goal  of  the  Agreements  in  this  clause  is  to  define  the  minimal  set  of  features  which  are  necessary  to 
provide  useful  Message  Store  services,  independent  of  the  MTA  implementation  version  (I.e.,  1984  or  1988). 

6.2  Scope 

The  scope  of  the  Agreements  in  this  clause  is  depicted  in  figure  5,  and  is  confined  to  the  services  and 
protocols  between  the  boundaries  shown  (marked  with  asterisks).  Requirements  for  the  UA  and  MTA  are 
addressed  only  to  the  extent  that  they  affect  the  Message  Store  and  Remote  User  Agent  services  and 
protocols.  This  reflects  the  additional  sen/ices  required  at  the  UA  to  support  MS  access  and  at  the  MTA  to 
support  a  remote  MS. 


Figure  5  -  Scope  of  message  store  agreements 

The  UA,  MS  and  MTA  configuration  is  not  restricted;  any  of  these  components  may  be  collocated,  although 
they  are  depicted  as  logically  separate,  in  the  case  of  a  collocated  UA  and  MS,  a  proprietary  interface  may 
be  used  instead  of  P7.  In  the  case  of  a  collocated  MS  and  MTA,  a  proprietary  interface  may  be  used  instead 
of  P3. 


6.3      Elements  of  service 


This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  to  provide  a  Message  Store 
conforming  to  the  Message  Store  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

Support  for  Elements  of  Service  is  specified  in  table  4  both  for  the  Message  Store  itself  and  for  the  User 
Agent. 


i 
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Table  4  -  MesMg*  ttora:  •toments  of  Mrvico 


Element  of  Service 

UA 

MS 

MS  Register 

0 

M 

Stored  Message  Deletion 

M 

M 

Stored  Message  Fetching 

M 

M 

Stored  Message  Listing 

M 

M 

Stored  Message  Summary 

M 

M 

Stored  Message  Alert 

0 

0 

Stored  Message  Auto  Forward 

0 

0 

1 6.4     Attribute  types 

{Requirements  for  support  of  the  attributes  used  in  the  Message  Store  are  detailed  in  clauses  A.8  and  A.9. 
I  There  are  two  levels  of  support  for  General  Attributes  in  the  Message  Store. 

I  The  Basic  MS  Is  intended  to  support  the  use  of  the  MS  as  a  continuously  available,  reliatMe  device  (such 
as  a  spooling  entity)  for  receiving,  storing,  and  forwarding  messages  and  reports.  The  Basic  MS  is  not 
required  to  support  any  content-specific  attributes. 

The  Enhanced  MS  supports  a  larger  number  of  general  attributes  and  is  suited  to  MSs  that  also  support 
I  content-specific  attritbutes. 

Additionally,  support  for  security  attributes  is  defined  in  clause  A.9,  for  use  in  secure  environments. 
!  Refer  to  the  content-specific  clauses  for  support  for  content-specific  attributes. 


j6.5     Pragmatic  constraints  for  attribute  types 

There  are  no  additional  pragniatlc  constraints  for  attribute  types  beyond  those  of  the  base  standards. 

! 

1 6.6     MS  access  protocol  (P7) 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  elements  by  an  MS  and  a  remote  MS-user  are 
^  detailed  in  clause  A.4. 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  application  contexts  by  an  MS  and  an  MS-user 
are  as  specified  in  clauses  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the  additional  requirement  that 
lian  MS-user  must  at  least  support  the  ms-access  application  context,  as  defined  in  table  5. 


I 
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Table  5  -  Application  contexts  support  for  P7 


Application  Context 

MS 

MS-user 

ns-access 
Bs-reliable-access 

Mandatory 
Optional 

Mandatory 
Optional 

Use  of  the  underlying  services  to  support  tiiese  ai^piication  contexts  is  specified  in  clause  15. 


6.7     MTS  Access  Protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements  by  an  MTA  and  an  MS  where  the  MS 
is  not  coliocated  with  the  MTA  are  detailed  In  clause  A.3. 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  application  contexts  by  an  MTA  and  an  MS  in 
such  a  scenario  are  as  specified  In  sections  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the  additional 
requirement  that  a  remote  MS  must  at  least  support  the  mts-access  and  mts-forced-access  application 
contexts,  as  defined  in  table  6. 


Table  6  -  Application  contexts  support  for  P3 


Application  Context 

MTA 

MS 

mts-access 
mts-£orced-access 
mts-rel iable-access 
mts-forced-reliable-access 

Mandatory 
M2uidatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  15. 


7    Remote  user  agent  support 


7.1  Introduction 

This  dause  specifies  Agreements  for  implementation  of  the  Remote  User  Agent  Functional  Group,  I.e.,  for 
support  of  an  UA  that  Is  not  collocated  with  its  MTA. 

The  goal  of  the  Agreements  in  this  clause  is  to  define  the  minimal  set  of  features  which  are  necessary  to 
provide  useful  Remote  User  Agent  services,  independent  of  the  MTA  implementation  version  (i.e..  1984  or 
1988).  artd  independent  of  any  particular  content  type.  The  content-specific  requirements  for  UAs  are 
specified  in  the  content-specific  sections  of  this  part  of  the  Implementor's  Agreements. 
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7.2  Scope 

The  scope  of  the  Agreements  In  this  clause  Is  depicted  In  figure  6,  and  Is  confined  to  the  services  and 
protocols  between  the  boundaries  shown  (marked  with  asterisks).  Requirements  for  the  UA  and  MTA  are 
addressed  only  to  the  extent  that  they  affect  the  Remote  User  Agent  services  and  protocols.  Access  to  a 
Message  Store  by  a  Remote  User  Agent  Is  covered  in  clause  6. 


Figure  6  -  Scope  of  remote  user  agent  agreements 


7.3     Elements  of  service 


This  dause  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Remote 
User  Agent  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  In  clause  5.2. 

Support  for  Elements  of  Service  Is  specified  for  the  MT  Service  (table  7)  and  Is  in  addition  to  the  support 
requirements  specified  in  clauses  5  and  13  If  this  Functional  Group  Is  supported. 

Table  7  -  Remote  user  agent  support:  MT  elements  of  service 


Element  of  Service 

Origination 

Reception 

Access  Management 

M 

M 

Hold  £or  Delivery 

M 

User/UA  Capabilities  Registration 

M 

7.4      MTS  access  protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements  by  an  MTA  and  an  MTS-user  (whether 
UA  or  UA/MS)  where  the  MTS-user  is  not  collocated  with  the  MTA  are  detailed  in  clause  A.3. 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  application  contexts  by  an  MTA  and  an  MTS-user 
in  such  a  scenario  are  as  specified  In  sections  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the 
addttional  requirement  that  a  remote  MTS-user  must  at  least  support  the  mts-access  and  mts-forced-access 
applteation  contexts,  as  defined  In  table  8. 
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Tabl«  8  •  Application  contoxts  support  for  P3 


Application  Context 

MTA 

MTS-user 

mts-access 
mts-forced-access 
mts-reliable-access 
mts-forced-reliable-access 

Meuidatory 
Mzmdatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underiying  services  to  support  these  application  contexts  is  specified  in  clause  15. 


8     Naming,  addressing  &  routing 


8.1      Use  of  0/R  addresses  for  routing 

Procurers  are  responsible  for  understanding  the  implications  of  routing  requirements  and  capabilities. 


8.2      ORAddress  attribute  list  equivalence  rules 

Two  ORAddresses  are  equivalent  if  each  contains  the  same  set  of  attributes  and  each  attribute  compares 
in  type  and  value. 

The  following  equivalence  rules  apply  when  comparing  a  provided  ORAddress  with  a  collection  of  known 
ORAddresses.  For  example,  in  order  to  perform  delivery  of  a  mes^ge  to  a  recipient,  the  MTA  must  f 
unambiguously  match  the  ORAddress  contained  in  the  message  with  the  known  ORAddresses.  See  X.402 
(1988),  section  18.4,  for  the  t>ase  standard  attribute  equivalence  rules.  The  following  additional  rules  must 
also  be  applied  by  the  delivering  (or  non-delivering)  MTA: 

a)  If  the  provided  ORAddress  is  an  unambiguous  underspecification  of  a  known  ORAddress.  the 
ORAddresses  are  equivalent.  For  example,  if  the  initials  were  omitted,  the  ORAddress  would  still  be 
equivalent.  Under-specification  means  that  some  attributes  that  are  not  present  in  the  provided 
ORAddress  are  present  in  the  known  ORAddresses.  Under-specification  does  not  mean  partial  value 
(e.g.,  substring)  equivalence  when  the  same  set  of  attributes  are  present  in  the  ORAddresses. 

b)  Over-specified  ORAddresses  are  not  equivalent.  Over-specification  means  that  more  attributes 
are  present  in  the  provWed  ORAddress  than  are  present  in  the  known  ORAddresses,  however, 
unrecognized  DDA  types  may  be  ignored  for  these  purposes. 

c)  An  ADMD  or  PRMD  name  that  is  all  numeric  but  encoded  as  Printat>le  String  is  conskiered  to 
be  equivalent  to  the  same  ADMD  or  PRMD  name,  respectively,  with  the  same  numeric  values 
encoded  as  Numeric  String. 

d)  An  extension  attribute  encoded  as  Teletex  String  shall  t>e  compared  with  the  corresponding 
standard  attribute  encoded  as  Printable  String  if  that  extension  attribute  is  not  present  in  both 
ORAddresses.  Matching  rules  are  as  specified  in  clause  18.4  of  X.402  (1988)  (as  modified  in  the 


16 


Part  8:  Message  Handling  Systems 


December  1992  (Stable) 


MHS  Implementors'  Guide)  except  that  only  teletex  graphic  characters  from  repertoire  no.  102  need 
to  be  compared  for  Printable  String  equivalence  (I.e.,  the  presence  of  graphic  characters  from  other 
repertoires  can  be  treated  as  a  mismatch). 

NOTES 

1  An  X.500  Directory  service  may  or  may  not  support  these  matching  rules  for  equivalence. 

2  Operational  equivalence  between  T.61  an  Printable  String  is  for  ftjrther  study. 


8.3      Distribution  lists 


8.3.1  Introduction 

This  clause  identifies  and  specifies  the  Distribution  Lists  Functional  Group,  which  covers  all  issues  relating 
to  the  performance  of  distribution  list  (DL)  expansion  by  an  MTA.  Other  aspects  concemed  with  the  use  of 
distribution  lists  are  covered  in  the  MT  Kernel  Functional  Group. 


8.3.2       Elements  of  service 

This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Distribution 
Lists  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

Support  for  Elements  of  Sen/ice  is  specified  for  the  MT  Service  only  (table  9),  and  is  only  concemed  with 
the  performance  of  DL  expansion  by  an  MTA.  Such  support  is  in  addition  to  the  support  requirements 
specified  in  clause  5  If  this  Functional  Group  is  supported. 


Table  9  -  Distribution  lists:  MT  elements  of  service 


Element  of  Service 

Support 

DL  Expansion  History  Indication 

M 

DL  Expansion  Prohibited 

M 

Use  of  Distribution  List 

Ml 

Notes 

1    Use  of  DL  Neunes  is  always  possible 

because  a  DL  name  cannot  be 

distinguished  from  any  other  OR  Ncune 

on  origination. 
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8.4     MHS  use  of  Directory 


8.4.1  Introduction 

The  MHS  standards  recognize  the  need  of  MHS  users  for  a  number  of  directory  service  elements.  Directory 
service  elements  are  intended  to  assist  users,  their  UAs,  and  MTAs  in  obtaining  information  for  use  in 
submission,  delivery,  and  the  transfer  of  messages. 

NOTE  -  The  MTS  may  also  use  the  directory  service  elements  to  obtain  information,  for  example,  to  be  used 
in  the  routing  of  messages.  This  application  of  the  directory  service  is  not  defined  by  the  base  standards  and 
Is  therefore  not  addressed  by  this  Agreement. 


8.4.2       Functional  configuration 

Two  MHS  functional  entities,  the  UA  and  MTA,  may  access  the  Directory  service  using  the  Directory  User 
Agent  pUA).  The  interface  t>etween  the  UA  and  DUA,  or  MTA  and  DUA  is  local  and  not  defined.  The 
interaction  between  the  DUA  and  Directory  System  Agent  (DSA)  is  specified  in  part  11.  A  collocated  DUA 
and  DSA  is  also  permitted. 


8.4.3  Functionality 

Examples  of  functional  usages  of  directories  have  been  identified  for  UAs  and  the  MTAs  in  conjunction  with 
their  DUAs.  These  are: 

a)  UA  Specific  Functionality: 

1)  Verify  the  existence  of  a  Directory  Name; 

2)  Given  a  partial  name,  return  a  list  of  possibilities; 

3)  Search  the  Directory  for  entries  containing  a  specified  attribute  type  and  value  and 
retum  the  Distinguished  Names  of  the  matching  entries; 

4)  Retum  the  0/R  Address(es)  that  correspond  to  a  Directory  Name; 

5)  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  Distribution  List; 

6)  Retum  the  members  of  a  Distribution  Ust; 

7)  Retum  the  capabilities  of  the  entity  refen'ed  to  by  a  Directory  Name; 

8)  Maintenance  functions  to  keep  the  directory  up-to-date,  e.g.,  register  and  change 
credentials. 

b)  MTA  Specific  Functionality: 
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2)  Return  tlie  0/R  Address(es)  that  correspond  to  a  Directory  Name; 

3)  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  DIstributbn  Ust; 

4)  Return  the  members  of  a  Distribution  Ust; 

5)  Return  the  capabiiities  of  the  entity  referred  to  by  a  Directory  Name; 

6)  Maintenance  functions  to  l<eep  the  directory  up-to-date. 

In  addition  to  functionality,  a  number  of  operational  aspects  must  be  considered.  These  include 
user-friendliness,  flexibility,  availability,  expandability  and  reliability. 


I  8.4.4       Naming  and  attributes 

j  Since  user-friendliness  is  of  primary  importance  in  a  messaging  system,  the  naming  conx'entions  used  In 
'  building  the  Directory  Information  Tree  (DIT)  will  impact  the  ability  of  a  user  to  mai<e  intelligent  guesses  for 
Directory  Names. 

!  It  Is  recommended  that  the  naming  guidelines  and  DIT  structures  defined  in  Annex  B  of  Recommendation 
X.521/ISO  9594-7  be  used  as  the  basis  for  MHS  Directory  Names.  Annex  C  of  Recommendation  X.402/ISO 
'  10021-2  specifies  further  the  MIHS  specific  object  classes.  The  naming  for  MHS  specific  object  classes  are 
\  recommended  as  follows: 

a)  The  naming  for  mhs-message-store,  mhs-message-transfer-agent,  and  mhs-user-agent  is  that 
of  Application  Entity  in  the  DIT; 

b)  The  naming  attribute  for  mhs-distribution-list  is  commonName.  The  organization, 
organizationalUnit,  organizationalRole,  organizationalPerson,  locality,  or  groupOfNames  can  be 
immediate  superior  to  entries  of  object  class  mhs-distribution-list; 

il 

"  c)  The  naming  for  mhs-user  is  that  of  organizationalPerson,  residentialPerson,  organizationalRole, 

I  organizationalUnit,  organization,  or  locality. 

ii 

|i  NOTE  -  The  mhs-user  object  class  is  a  generic  object  class  which  may  be  used  in  conjunction  with  another 

standard  object  class  for  the  purpose  of  adding  MHS  information  attributes,  such  as  ORAddresses,  to  a 

jjj  Directory  entry.  The  means  to  associate  attributes  of  a  generic  object  class  to  an  entry  (or  to  different  entries) 

III  named  by  a  standard  object  class(es)  is  by  defining  a  new  (un-)registered  object  class,  whose  superclass(es) 

is  that  of  the  naming  object  class(es),  and  of  the  generic  object  class.  E.g.,  to  associate  mhs-user  attributes 

-  in  the  organizationalPerson  entry,  a  new  unregistered  object  class  can  be  defined  as  shown  in  figure  7. 
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real-user-entry    : ; 

:=    OBJECT  CLASS 

SUBCLASS  OF  orgemizationalPerson, 

mhs-user 

Figure  7  -  Example  of  unregistered  object  class  definition 


The  MHS  object  classes,  attributes,  and  attribute  syntaxes  tliat  need  to  be  supported  by  the  Directory  are 
as  specified  in  Annex  C  of  Recommendation  X.402/iSO  10021-2. 

in  addition,  the  object  ciasses  organization,  organizationalUnit,  organizationalRole,  organizationalPerson, 
iocallty,  groupOfNames,  residentiaiPerson,  and  country  and  their  attributes  and  associated  syntaxes  as 
defined  in  X.520  (iSO  9594.  Part  6)  and  X.521  (ISO  9594,  Part  7)  are  required  to  support  the  MHS. 


8.4.5       Elements  of  service  « 

This  ciause  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Use  of  I 
Directory  Functional  Group  of  this  Agreement.  | 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  ciause  5.2. 

I 

Support  for  Elements  of  Sen/ice  is  specified  both  for  the  MT  Sen/ice  (table  10).  j 


Table  10  -  Use  of  directory:  MT  elements  of  service 


Element  of  Service 

Origination 

Reception 

Relay 

Designation  of  Recipient  by 
Directory  Vlame 

M 

M 

8.4.6       Directory  services 

These  implementation  Agreements  require  the  Directory  services  as  defined  in  tabtle  11.  Indicated  are  the 
Directory  services  required  to  support  the  needs  of  the  MHS  UA/MTA  and  MHS  Administrator. 

i 
I 
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Table  1 1  -  Directory  service  support  requirements 


MHS 

MHS 

Directory  Service 

UA/MTA 

Admin 

Bind  and  Unbind 

M 

M 

Read 

M 

M 

Compare 

M 

M 

Ab2mdon 

M 

M 

List 

M 

M 

Search 

M 

M 

Add  Entry 

0 

M 

Remove  Entry 

0 

M 

Modify  Entry 

M 

Modify  RON 

0 

0 

8.4.7       OIW  X.400  base  Directory  implementation  Agreements 

This  clause  defines  the  X.400  base  Directory  Implementation  Agreements.  Its  structure  and  content  are 
based  on  the  Implementation  Agreements  template  suggested  in  part  1 1 . 


8.4.7.1        Other  profiles  supported 

The  OIW  X.400  Base  Directory  Implementation  Agreements  requires  the  support  of  OIW  Directory  Common 
Application  Directory  Implementation  Agreements  as  defined  in  part  1 1 . 


8.4.7.2        Standard  application  specific  attributes  and  attribute  sets 

The  standard  application  specific  attributes  and  attributes  sets  supported  by  these  Implementation 
Agreements  are  listed  in  table  12.  For  each  attribute  and  attribute  set,  a  reference  is  provided  to  the  standard 
where  it  is  defined. 


Table  12  -  Standard  attributes  and  attribute  sets 


Attribute  /  Attribute  Set 

References 

mhs-deliverable-content-length 

mhs-deliverable-content-types 

mhs-deliverable-eits 

mhs-dl-members 

mhs-dl-submit-permissions 

mhs-message-store 

mhs-or-addresses 

mhs-prefer red-deli very-methods 

mhs-suppor t ed-automat  i  c-ac t  ions 

mhs-supported-content-types 

mhs-supported-optional-at tributes 

X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 

I 

I 
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8.4.7.3        Standard  application  specific  object  classes  ' 

The  standard  application  specific  object  classes  supported  by  tiiese  implementation  Agreements  are  listed  ' 
in  table  13.  For  eacii  object  class,  a  reference  is  provided  to  tlie  standard  wliere  it  is  defined. 


Table  13  -  Standard  object  classes 


Object  Class 

References 

mhs-distribut ion-list 

mhs-message-store 

mhs -mes s age- t r ans f e r -agent 

mhs-user 

mhs -user -agent 

X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 

8.4.7.4        OIW  application  specific  attributes  and  attribute  sets  i 

There  are  no  application  specific  attributes  or  attribute  sets  defined  by  these  Implementation  Agreements,  ii 


8.4.7.5        OIW  application  specific  object  classes 

There  are  no  application  specific  object  classes  defined  by  these  Implementation  Agreements. 


8.4.7.6        Structure  rules 

This  clause  defines  the  naming  and  structure  rules  for  the  MIHS  object  classes  which  are  sutx^lasses  of  top. 


8.4.7.6.1  MHS  Distribution  Ust 

Attribute  commonName  Is  used  for  naming.  , 

The  mhs-distribution-list,  organization,  organizationalUnit,  organizationalRole,  organlzatlonalPerson,  locality, ' 
or  groupOfNames  can  be  immediately  superior  to  entries  of  object  class  mhs-distributlon-list. 


8.4.7.6.2  MHS  User 

The  naming  for  mhs-user  is  that  of  organlzatlonalPerson,  residentialPerson,  organizationalRole, 
organizationalUnit,  organization,  or  locality. 

I' 

The  organlzatlonalPerson,  resldentialPerson,  organizationalRole,  organizationalUnit,  organization,  or  locality |^ 
object  classes  can  be  combined  with  the  mhs-user  object  class  to  form  a  new  composite  object  class,  j 

i 

I 

■J' 
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8.4.7.7 


Use  of  Capabilities  Information 


The  capabilities  Information  In  the  X.500  Directory  should  not  t>e  considered  sufficient  to  warrant  a  non- 
delivery decision  by  an  originating  or  relaying  MTA.  This  clause  Is  not  Intended  to  impose  any  confonmance 
requirement. 


8.5     Address  support  for  Teletex  character  sets 

This  dause  identifies  the  Address  Support  for  Teletex  Character  Sets  Functional  Group,  which  covers  the 
generation  of  Teletex  strings  in  OR  Address  components. 


I  Support  of  this  functional  group  implies  that,  If  an  address  component  is  supported  for  origination,  the 
!  corresponding  Teletex  component  (if  any)  must  be  supported  for  origination. 


8.6      Reply  support 

When  originating  a  reply,  the  UA  must  be  able  to  utilize  the  applicable  addressing  components  of  the 
message  to  which  it  is  replying  (regardless  of  character  set  support  level). 


i  9    MHS  management 

NOTE  -  For  further  study. 


The  Security  functional  group  is  specified  as  three  security  classes  which  are  incremental  sut>sets  of  the 
security  features  available  in  the  base  standard.  They  are  denoted  as  SO.  Si,  and  S2.  An  Implementation 
that  conforms  to  the  Security  functional  group  map  support  one  or  more  of  the  security  classes  defined  in 
these  Implementation  Agreements. 


(  SO:  This  security  dass  gathers  together  security  functions  applicable  only  between  MTS-Users. 
i  Consequently,  security  mechanisms  are  implemented  within  the  MTS-User.  An  MTA  is  required  to  support 
J  the  syntax  of  the  security  services  on  submission,  as  the  "Kemel"  supports  the  syntax  on  relay  and  delivery. 
I  The  MTA  is  not  expected  to  understand  the  semantics  of  the  securi^  sen/ices. 

I  Si:  This  security  dass  requires  secure  functionality  with  the  MTS-User  and  MTS.  The  MTS  secure 
I  functionality  is  only  required  to  achieve  secure  access  management.  As  with  SO.  most  of  the  security 

I  mechanisms  are  implemented  within  an  MTS-User.  It  primarily  provides  integrity  and  authentication  between 

I I  MTS-Users.  However,  MTAs  are  expected  to  support  digital  signatures  for  peer  to  peer  authentication, 
security  labelling  and  security  contexts. 


10 


MHS  security 


10.1  Overview 
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S2:  This  security  dass  is  a  superset  of  S1,  adding  security  functions  witiiin  MTAs  and  tfie  MTS.  Tlie  main 
security  function  added  within  this  group  is  authentication  within  the  MTS,  and,  as  a  consequence,  due  to 
the  non-repudiable  nature  of  the  keys  used  for  authentication,  non-repudiation  is  also  added. 

In  addition,  each  of  the  three  security  classes  has  a  variant,  denoted  as  SOa,  S1a,  and  S2a,  which  mandates 
support  of  erxJ-to-end  confidentiality. 

Symmetric  or  asymmetric  techniques  (or  a  combination  thereof)  may  be  used  within  each  security  class  and 
are  identified  by  the  registered  algorithm  identifier. 

Various  levels  of  assurance  in  trusted  COMPUSEC  functionality  may  be  used  within  each  security  class.  This 
is  outside  the  scope  of  this  Implementors  Agreement. 

A  full  rationale  for  each  of  the  security  classes  and  a  broader  discussion  of  security  considerations  are 
provided  in  annex  E. 

Table  14  provides  an  overview  of  the  requirements  made  by  the  security  classes  on  the  MTS-User  and  MTA. 
The  table  entries  are  descriptive,  and  are  not  intended  to  refer  to  security  service  elements. 


Table  14  -  Overview  of  security  requirements  for  each  security  class. 


Class 

Requirements 

MTS-User 

MTA 

Kernel 

Submission,  delivery,  and 
relay  of  EoS 

SO 

Content  Integrity,  Proof  of 
Delivery,  Message  Origin 
Authentication  (UA  to  UA) 

Kernel 

SOa 

SO  plus  Content 
Conf  i  dent  i  al i  ty 

Kernel 

SI 

SO  plus  Message  security 
label.  Message  security 
context.  Security  Management 
Services 

Peer  entity  authentication. 
Security  context.  Security 
Management  Services,  and 
Message  Security  Label 

Sla 

SI  plus  Content 
confidentiality 

SI 

S2 

SI  plus  Message  Origin 
Authentication  Check,  Probe 
Origin  Authentication  Check, 
Report  Origin  Authentication 
Check,  Proof  of  Submission, 
and.  Non-repudiation 

SI  plus  Message  Origin 
Authentication  Check,  Prove 
Origin  Authentication  Check, 
Report  Origin  Authentication 
Check,  Proof  of  Submission, 
and.  Non-repudiation 

S2a 

Sla  plus  S2 

Sla  plus  S2 
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The  incremental  functionality  of  the  security  classes  can  be  represented  diagramnnatically  as  shown  in  figure 
8. 


SO 

1 

\ 

! 
1 

SOa 

SI 

1 
1 

\ 

1 
1 

Sla 

S2 

\ 

S2a 

Figure  8  -  Incremental  functionality  of  the  security  classes 


0.2    Common  requirements 


1 1 0.2.1      Interworking  between  security  classes 

i\  security  class  can  be  viewed  as  a  tool  which  can  be  used  to  Implement  a  security  policy,  and  is  not  a 
iwcurity  policy  in  its  own  right  but  a  component  of  a  security  policy. 

nterworl<ing  between  implementations  supporting  different  security  classes  can  be  achieved  in  terms  of  any 
pommon  class(es)  supported.  As  specified  in  the  base  standard,  the  label  of  the  message,  probe  or  report 
I  jinust  be  checked  against  the  security  context  by  any  implementation  claiming  conformance  to  classes  S1, 
1^1  a,  S2,  and  S2a. 

NOTE  -  Interworking  can  be  limited  to  messages  of  only  one  security  class  by  defining  a  security  context 
consisting  of  labels  with  security  policy  identifiers  of  only  that  security  class. 

his  profile  defines  security  policy  identifiers  (annex  B,  figure  18)  that  corresponds  to  the  security  classes 
efined  in  this  section.  Such  generic  security  policy  identifiers  only  imply  support  of  the  X.400  security 
!  services  as  specified  for  these  security  classes  in  this  clause.  No  other  COMSEC  or  COMPUSEC 
ipnctionaiity  can  be  assumed  by  use  of  such  policy  identifiers.  More  specific  security  policies  may  be  based 
i|tn  one  or  more  of  the  security  classes  in  this  section  but  will  require  use  of  registered  policy  identifiers. 

I 

|o.2.2     Comparison  of  security  labels 

I  [he  Security  Content  service  ensures  that  the  message  security  label  matches  at  least  one  of  the  set  of 
libels  specified  in  the  security  content  established  between  the  communicating  MHS  entities. 

n  MTA  which  supports  the  Security  Content  service  shall  as  a  minimum  support  matching  for  equality  on 
security-policy-identifier,  security-classification,  and  security-categories  elements  of  the  iat>el. 
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NOTE  -  The  basic  support  requirement  is  that  absence  of  an  element  shall  not  be  treated  as  'any  value,*  i.e., 
all  permissible  combinations  of  occurrence  and  value  for  the  elements  of  the  message  security  label  must  be 
elaborated  in  the  security  context. 

Any  other  matching  rules  (e.g.,  covering  the  privacy-mark  element  or  based  on  alternative  methods  of 
comparison  nnay  l3e  used  in  particular  application  scenarios,  but  such  specification  and  usage  will  be  subject  i 
to  bilateral  agreement  and  will  depend  on  the  security  policy  in  force. 

The  message  security  label  can  be  placed  in  the  per-message  extensions  or  in  the  signed  or  encrypted  data 
of  the  per-recipient  message  toi<en.  It  is  recommended  that  the  integrity  of  the  security  lat>el  Is  protected 
by  including  it  in  the  tol<en  signed  data,  or  (if  the  label  is  in  the  per-message  extensions)  by  computing  the  i 
message  origin  authentication  checl<  on  the  message.  (Support  of  MOAC  Is  optional  In  security  classes  SO 
and  SI.)  Which  of  these  labels  is/are  checked  by  the  security  context  service  Is  dictated  by  the  security  ' 
policy  in  force.  The  security  policy  should  also  define  any  requirements  on  allowable  (per-reciplent)  label 
values  in  the  case  where  the  message  is  addressed  to  multiple  recipients  (and  thus  has  multiple  tokens). 

A  label  may  also  be  included  in  the  token  encrypted  data  with  (confkiential)  end-to-end  semantics. 


10.2.3     Application  context 

When  providing  the  peer  entity  authentication  service,  it  is  recommended  that  MTAs  should  not  use  the  | 
"association-recovery"  procedure  of  RTSE  (section  7.8.3  of  X.228).  MTAs  in  the  role  of  sender  should  not 
invoke  this  procedure  and  MTAs  in  the  role  of  receiver  should  not  accept  RT-OPEN  requests  asking  for  \ 
recovery. 

NOTE  -  It  is  permissible  for  the  sending  MTA  to  perform  the  'activity  resumption'  (sec.  7.8.1  of  X.228)  on  an 
existing,  authenticated  RTSE  association  owned  by  this  MTA.  > 


The  sections  to  follow  describe  the  security  classes  within  the  Security  functional  group.  For  each  security 
class,  there  is  a  description  of  the  security  functionalities  provided,  followed  by  a  table  which  gives  the  i 
classification  for  each  of  the  security  services  required  by  that  class.  Where  the  classification  of  a  security 
service  does  not  cliange  for  a  higher  security  class,  then  that  security  service  is  not  repeated  In  the  table 


Figure  9  explains  the  column  headings  used  in  the  security  class  tables.  The  classifications  are  defined  In 
clause  5.2. 


10.3    Description  of  security  classes 


for  the  higher  security  class. 
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r 


UA 

MS 

1  MTA 

MTA 

MS 

J    L3_l     L«_J  Ls- 

J|  L 

UA 


1:  UA/UA 
2:  UA/MS 
3:  MS/MTA 


Legend 

4:  UA/MTA 
5:  MTA/MS 
6:  MTA/MTA 


7:  MTA/UA 

8:  MS/Originating  UA 
9:  MS/Recipient  UA 


Figure  9  -  Security  interfaces 

10.4    Security  class  0  (SO) 

10.4.1  Security  functionality 

Security  measures  shall  be  provided  by  ttie  MHS  implementation  in  order  to  provide  tlie  following: 

a)  integrity  of  message  content; 

b)  Autlientication  of  the  MTS-User  who  originated  the  message; 

c)  Authentication  of  the  MTS-User  to  whom  the  message  was  delivered. 
This  security  dass  mandates  the  above  services  are  provided  by  an  MTS-User. 
There  are  no  requirements  placed  on  the  MTA. 

10.4.2  Security  services  for  SO 

Security  class  0  (SO)  mandates  the  security  services  listed  in  table  15. 
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Table  15  -  Security  class  0  (SO) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication^ 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 
Proof  of  Delivery 

M 
M 

Is 

I 
I 

I 

I 

I 
I 

- 

Secure  Access  Management 

Peer  Entity  Authentication^*' 
Security  Context 

- 

0 
0 

0 
0 

0 
0 

0 
0 

0 
0 

0 
0 

- 

0 
0 

Data  Confidentiality 

Connection  Confidentiality^ 
Content  Confidentiality 
Message  Flow  Confidentiality 

- 
I 
I 

I 

I 

I 

I 

I 

I 

— 

I 

Data  Integrity  Services 
Connection  Integrity^ 

Message  Sequence  Integrity^^ 

M 

0 

I 

I 

I 

I 

I 

I 

I 

Non-Repudiation 

Non-Repudiation  of  Origin^ »^ 
Non-Repudiation  of  Submission 
Non-Repudiation  of  Delivery^ 

0 
0 

I 

I 

0 

Message  Security  Labelling^ 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Security  Management  Services 
Chemge  Credentials 
Register 
MS-Register 

ooo 

0 
0 

0 

l9 

0 
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Notes 

1  Only  provided  to  the  message  recipient. 

2  Using  either  symmetric  or  asymmetric  algorithms  as  identified 
by  the  algorithm  identifier  in  the  applicable  protocol  element. 

3  ^en  security  labelling  is  used,  the  security  policy  identifier  shall 
be  included. 

4  If  Proof  of  Delivery  and  Content  Confidentiality  are  both  used,  and 
delivery  is  to  2Ui  MS,  then  proof  of  delivery  can  only  be  computed  on  the 
encrypted  content.  It  should  be  noted  that  this  will  not  provide 
non-repudiation  of  delivery. 

5  Using  either  a  trusted  notary  (symmetric)  or  using  certificates 
tokens  which  are  not  repudiable  (asymmetric). 

6  Corrects  table  7  of  X.402  in  the  base  standard. 

7  Authentication  between  collocated  objects  is  a  local  issue. 

8  Refer  to  section  10  of  X.402  and  ISO/IEC  10  021-2  and  IS  7498-2. 

9  These  services  are  expected  to  be  provided  by  non-standard 
management  services  and  are  therefore  outside  the  scope  of  this 
Implementors  Agreement. 

10  Non-Repudiation  of  Delivery  can  only  be  provided  when  the 
proof-of-delivery  service  is  used. 

11  Allocation  and  management  of  sequence  numbers  is  outside  the 
of  this  Implementors  Agreement  (as  it  is  subject  to  bilateral 
agreements ) . 


10.5    Security  class  OA  (SOa) 


10.5.1      Security  functionality 

Security  measures  shall  be  provided  by  the  MHS  Implementation  in  order  to  provide  the  following: 

a)  Security  Functionality  defined  in  security  class  SO;  and, 

b)  Content  Confidentiality. 


10.5.2      Security  services  for  SOa 

Security  class  OA  (SOa)  mandates  the  security  services  of  class  SO  plus  those  listed  in  table  16. 


Table  16  -  Security  class  OA  (SOa) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 
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10.6    Security  class  1  (SI) 

10.6.1  Security  functionality 

Security  measures  shall  be  providecl  by  the  MHS  implemenlatlon  in  order  to  provide  the  following: 

a)  Authentication  of  MTA.  MS.  and  UA; 

b)  ConHdentlailty  of  connections  between  MTA.  MS.  and  UA; 

c)  Integrity  of  message  content; 

d)  Authentication  of  message  originator  i 

e)  Authentication  of  message  delivery  (Proof  of  delivery);  * 

f)  MLS-features  of  MTA.  MS.  and  UA; 

g)  MLS-separation  of  messages,  probes,  and  reports;  and,  ^ 

h)  MLS-mediation  by  secure  access  measures. 

NCHES  ! 

1  The  level  of  assurance  of  the  MLS  trusted  components  is  subject  to  bilateral  agreement 

2  The  level  of  accountability  provided  is  subject  to  bilateral  agreenient.  ! 

10.6.2  Security  services  for  SI  ) 

Security  dass  1  (Si)  mandates  the  security  servicesof  dass  SO  plus  those  listed  in  table  17.  j 


1 

J 

t 
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Table  17  -  Security  class  1  (Si) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication^ 

Ml 

I 

I 

Secure  Access  Management 
Peer  Entity  Authentication-^ 
Security  Context 

Ml 

m1 

Ml 

m1 

m1 

m1 

m1 

Data  Integrity  Services 
Content  Integrity 

Ml 

Message  Security  Labelling^ 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Security  Management  Services 
Change  Credentials 
Register 
MS-Register 

M 
M 
M 

M 
M 

M 

l5 

M 

Notes 

1  Shall  always  be  used. 

2  Only  provided  to  the  message  recipient. 

3  Using  either  symmetric  or  asynmietric  algorithms  as  identified  by 
the  algorithm  identifier  in  the  applicable  protocol  element. 

4  Authentication  between  collocated  objects  is  a  local  issue. 

5  These  services  are  expected  to  be  provided  by  non-standard 
memagement  services  and  are  therefore  outside  the  scope  of  this 
Implementors  Agreement. 

10.7    Security  class  1 A  (SI  a) 

10.7.1  Security  functionality 

Security  measures  shall  be  provided  by  the  MHS  Implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  Si ;  and, 

b)  Content  Confidentiality. 

10.7.2  Security  services  for  SI  a 

Security  class  2A  (Si  a)  mandates  the  security  services  of  class  SI  plus  those  listed  in  table  18. 
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Table  18  -  Sdcurity  class  1A  (Sla) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 

10.8    Security  class  2  (S2) 

10.8.1  Security  functionality 

! 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  Si ;  and, 

b)  Authentication  and  non-repudiation  of  messages,  probes,  and  reports. 

10.8.2  Security  services  for  S2  [ 

I; 

Security  class  2  (S2)  mandates  the  security  services  of  class  S1  plus  those  listed  in  table  19.  i 


Table  19  -  Security  class  2  (82) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication^ 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 

Ml 

M* 

Ml 

Ml 

Ml 

M 

Non-Repud  i  a t  i  on 

Non-Repudiation  of  Origin 
Non-Repudiation  of  Submission 
Non-Repudiation  of  Delivery 

m5 

M^ 

m2 

m2 

Notes 

1  Shall  always  be  used. 

2  Using  an  asymmetric  mechanism  (i.e.,  certificates  and  tokens  which 
are  not  repudiable  for  authentication  within  MTAs  and  the  MTS. 

3  Using  the  Message  Origin  Authentication  Check  as  detailed  in  the 
base  standard. 

4  Shall  always  be  used,  and  corrects  table  7  in  X.402. 

5  Using  either  a  trusted  notary  (symmetric)  or  using  certificates 
tokens  which  are  not  repudiable  (asymmetric). 
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10.9.1  Security  functionality 

Security  measures  shall  be  provkled  by  the  MHS  Implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  dass  S2;  and, 

b)  Content  Confidentiality. 

10.9.2  Security  services  for  S2a 

Security  dass  2A  (S2a)  mandates  the  services  of  dass  S2  plus  those  listed  in  tat>le  20. 


Table  20  -  Security  class  2A  (S2a) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Data  Confidentiality 
Content  Confidentiality 

M 

1 1   Specialized  access 
11.1    Physical  delivery 

This  dause  identifies  and  specifies  the  Physical  Delivery  Functional  Group,  which  Is  intended  to  cover  all 
issues  relating  to  access  to  physical  delivery  systems  by  an  MIHS  implementation. 

11.1.1      Elements  Of  service 

This  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Physical  Delivery 
Functional  Group  of  this  Agreement. 

The  dassification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 
Support  for  Elements  of  Service  is  specified  for: 

a)  the  MT  Service  in  tat>le  21; 

b)  the  0/R  Address  Attributes  in  table  22;  and, 
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c)  the  character  string  support  in  table  23. 
Edttor's  Note  -  table  23  does  not  appear  in  this  part. 
NOTE  -  All  Elements  of  Sen/ice  listed  in  table  21  are  1988. 


Table  21  -  Physical  delivery:  MT  elements  of  service 


Element  of  Service 

UA  Origination 

PDAU  Reception 

Additional  Physical  Rendition 

0 

0 

Basic  Physical  Rendition 

M 

M 

Counter  Collection 

M 

M 

Counter  Collection  with  Advice 

0 

0 

Delivery  via  Bureaufax  Service 

0 

0 

EMS  (Express  Mail  Service) 

H 

M 

Ordinary  Mail 

M 

M 

Physical  Delivery  Notification 

by  MHS 

0 

0 

Physical  Delivery  Notification 

by  PDS 

0 

0 

Physical  Forwarding  Allowed 

M 

M 

Physical  Forwarding  Prohibited 

M 

M 

Registered  Mail 

0 

0 

Registered  Mail  to  Addressee 

in  Person 

0 

0 

Request  for  Forwarding  Address 

0 

0 

Special  Delivery 

M 

M 

Undeliverable  Mail  with  Return 

of  Physical  Message 

M 

M 

Table  22  -  Character  string  support 


Character  String 

Origination 
(UA) 

Reception 
(PDAU) 

Printable 
Teletex 

^  1 
0^ 

02 

Notes 

1  Mandatory  if  "Address  Support  for 
Teletex  Character  Sets"  functional 
group  is  supported. 

2  Mandatory  if  "Address  Support  for 
Teletex  Character  Sets"  functional 
group  is  supported,  with  a  minimum 
of  one  character  repertoire. 
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11 .2    Other  access  units 


11.2.1     Facsimile  access  units 

NOTE  -  The  possible  development  of  Agreements  In  this  area  is  for  further  study. 


11.2.2     Telex  access  units 

It  is  not  currently  Intended  to  develop  Agreements  In  this  area. 


11.2.3     Teletex  access  units 

It  is  not  cun'ently  intended  to  develop  Agreennents  in  this  area. 


12  Redirection 

The  redirection  functional  group  is  for  further  study. 


13  IPM  service 


;  13.1  Introduction 

j  This  clause  specifies  the  requirements  for  a  minimal  1988-t>ased  IPMS  implementation  (i  e.,  IPM  UA)  which 
Is  capable  of  Inteiworking  with  ig84-t)ased  UAs. 

1  Such  a  minimal  1 988-based  UA  will  have  the  following  capabilities  in  order  to  achieve  interworking  with  1 964- 
i  based  UAs  and  to  facilitate  migration  to  full  1988  operation: 

a)  It  wHI  continue  to  support  content  type  P2  (encoded  as  integer  2)  on  origination  and  reception; 

b)  It  wNI  support  receipt  of  P2  (encoded  as  integer  22); 

c)  It  may  originate  P2  encoded  as  integer  22.  but  the  guidelines  specified  in  section  8.18.2  of  X420 
(1988)  are  to  be  followed,  i.e.,  the  content  type  shall  be  encoded  as  integer  2  unless  1988  P2 
protocol  elements  are  present.Ali  IPM  UAs  must  support  either  MTS  Submission  and  Delivery  based 
on  the  protocol  classifications  in  clause  A.3,  or  MS  Sut}mission  and  Retrieval  based  on  the  protocol 
classifications  in  clause  A.4.  However,  how  such  information  is  conveyed  to/from  the  MTS  or  MS 
in  the  case  of  a  collocated  UA  is  a  local  matter,  and  will  not  necessarily  be  subject  to  conformance 
verification. 
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13.2    Elements  of  service 

This  clause  specifies  the  requirements  for  support  of  IPM  Eiements  of  Service  by  a  UA  conforming  to  the 
iPM  Kemel  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

The  requirements  for  support  of  IPM  Elements  of  Service  for  origination  and  reception  are  distinguished. 
Elements  of  Service  which  are  new  in  the  1988  MIHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  Basic  IPM  Elements  of  Service  and  IPM  Optional  User  Facilities  defined  in  section 
19  of  X.400  (1988)  as  listed  and  qualified  in  tables  23  and  24. 


Table  23  -  IPM  kernel:  basic  IPM  elements  of  service 


Element  of  Service 

Orig 

Recep 

Access  Management 

Ml 

Ml 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

Delivery  Time  Stamp  Indication 

M 

IP-message  Identification 

M 

M 

Message  Identification 

M 

Non-delivery  Notification 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  St£unp  Indication 

M 

M 

Typed  Body 

M 

"l 

User/UA  Capabilities  Registration  (1988) 

Ml 

Notes 

1    In  the  case  of  a  collocated  UA/MTA  or  collocated 

UA/MS,  the  method  and  extent  to  which  this  Element  of 
Service  is  provided  is  a  local  matter;  it  is  not 
necessarily  testable  in  the  absence  of  support  for  the 
P3  or  P7  protocol. 
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Table  24  -  IPM  kernel:  IPM  service  optional  user  facilKiet 


1 

Element  of  Service'^ 

Orig 

Recep 

Alternate  Recipient  Allowed 

0 

Alternate  Recipient  Assignment 

0 

Authorizing  users  Indication 

0 

M 

Auto— forwarded  Indication 

O 

n 

Blind  Copy  Recipient  Indication 

0 

M 

Body  Part  Encryption  Indication 

0 

M 

Conversion  Prohibition 

M 

n 

Conversion  Prohibition  in  Case  of  Loss  of 

Information  (1988) 

O 

O 

Cross  Referencing  Indication 

o 

n 

Deferred  Delivery 

H 

Deferred  Delivery  Cancellation 

r\ 
U 

Delivery  Notification 

H 

Disclosure  of  Other  Recipients 

O 

N 

DL  Expansion  History  indication  (i7ooi 

M 

DL  Expeuision  Prohibited  (1988) 

w 

n 

Expiry  Date  Indication 

O 

n 

Explicit  Conversion 

u 

Forwaraec  ir— message  inaicacion 

M 

1*1 

Graae  or  ueiivery  oexecbion 

M 

n 

Ml 

Hold  for  Delivery 

U 

Implicit  Conversion 

Importance  Indication 

U 

Incomplete  Copy  indication  (i9oo) 

yj 

Lemguage  indication  (iSBo) 

n 

M 

Latest  Delivery  Designation  (i9oo; 

n 

Nuiti— Destination  ijeiivery 

M 

Muiti— part  Body 

o 

M 

Non-receipt  Notification  Request 

0 

m2 

Obsoleting  Indication 

0 

M 

Originator  Indication 

M 

M 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

Prevention  of  Non-delivery  Notification 

0 

Primary  amd  Copy  Recipients  Indication 

M 

M 

Probe 

0 

Receipt  Notification  Request  Indication 

0 

0 

Redirection  Disallowed  by  Originator  (1988) 

0 

Redirection  of  Incoming  Messages  (1988) 

0 

Reply  Request  Indication 

0 

M 

Replying  IP-message  Indication 

M 

M 

Requested  Delivery  Method  (1988) 

M 
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Table  25  -  IPM  kernel:  IPM  service  optional  user  facilities  (concluded) 


Element  of  Service 

Orig 

Recep 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

Sensitivity  Indication 

0 

H 

Subject  Indication 

M 

M 

Use  of  Distribution  List  (1988) 

0 

Notes 

1  Other  UA  Elements  of  Service  are  listed  in  Table  4. 

2  Support  of  Non-Receipt  Notification  Request  on 
reception  does  not  require  the  capability  to  generate 
a  non-receipt  notification  in  the  case  of  an 
implementation  in  which  a  non-receipt  condition  c2mnot 
occur. 

13.3    Interpersonal  messaging  protocol  (P2) 

The  requirements  for  support  of  Interpersonal  Messaging  Protocol  (P2)  elements  are  detailed  in  clause  A.2. 


13.4    Body  part  support 

This  clause  specifies  the  requirements  for  support  of  IPM  IxxJy  part  types  by  a  UA  conforming  to  this 
Agreement. 

The  requirements  for  support  of  IPM  body  part  types  for  origination  and  reception  are  distinguished.  Body 
part  types  which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  IPM  body  part  types  defined  in  Annex  E  of  X.420  (1988)  as  listed  and  qualified  in 
table  33  of  Annex  A  of  this  part.  If  an  implementation  supports  a  particular  body  part  type  for  reception,  it 
should  also  be  able  to  support  that  body  part  type  for  reception  if  it  is  part  of  a  fonA^arded  message.  If  an 
implementation  supports  origination  of  fonA/arded  messages,  ft  must  be  capable  of  forwarding  every  body 
part  that  is  supported  on  reception.  The  reception  requirements  on  the  UA  do  not  necessarily  include  the 
ability  to  render  (display)  all  of  the  characters  received.  If  the  message  is  fooA^arded,  the  UA  must  transmit 
exactly  equivalent  characters,  but  not  necessarily  from  the  same  character  set. 

Any  basic  body  part  type  that  is  supported  on  reception  must  be  supported  as  integer  encoding  (ASN.1 
context-specific  identifier)  and  as  object  identifier  (externally-defined)  encoding. 

All  body  parts  with  integer-encoded  identifiers  in  the  range  0  up  to  and  including  16K-1  are  legal.  Body  part 
integer-encoded  identifiers  corresponding  to  X.121  country  codes  should  be  interpreted  as  described  in 
figure  10.  These  privately-defined  body  part  types  are  specified  as  an  interim  measure  to  provide  backward 
compatibility  with  1984  MHS  implementations.  For  intenworking  between  UAs  based  on  the  1988  (or  later) 
MHS  standards,  it  is  strongly  recommended  that  the  externally-defined  body  part  be  used  instead. 
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BodyPart 
ia5-text 


CHOICE  { 

tO]  lASTextBodyPart, 


oda-1984 
iso-6937 

bilaterally-defined 
externally-defined 


• 

[12]  IMPLICIT  OCTET  STRING, 

[13]  IS06937BodyPart, 

[14]  Unidentified, 

[15]  ExternallyDef inedBodyPart , 


[310]  IMPLICIT 

USAPrivatelyDef inedBodyParts , 


Unidentified  :=  OCTET  STRING 

The  content  of  the  ODA  OCTET  STRING  will  contain  a  value  of 
type  ODABodyPart  as  follows: 

ODABodyPart   :s=  SEQUENCE  { 
ODABodyPartParameters , 
OD/U^ata  } 

The  Parameters  and  Data  components  are  defined  in  Annex  E 
of  CCITT  Recommendation  T.4H  (1988)  (ISO  8613-1). 

USAPrivatelyDef inedBodyParts  are  defined  as: 


These  privately-defined  body  part  types  are  specified  as  an 
interim  measure  to  provide  backward  compatibility  with  1984 
MHS  implementations.    For  interworking  between  UAs  based  on 
the  1988  (or  later)  MHS  standards,  it  is  strongly 
recommended  that  the  externally-defined  body  part  be  used 
instead. 

The  undefined  bit  in  PI  EncodedlnformationTypes  must  be  set 
when  a  message  contains  a  privately  defined  body  part.  Each 
UA  that  expects  such  body  parts  should  include  undefined  in 
the  set  of  deliverable  EncodedlnformationTypes  it  registers 
with  the  MTA. 

Body  part  numbers  are  interpreted  relative  to  the  body  part 
type  in  which  they  are  used.    OIW  registers  body  part 
numbers  for  privately-defined  formats  within  the  United 
States. 


SEQUENCE  {BodyPartNumber,  ANY) 


BodyPartNumber 


: : =  INTEGER 


Figure  10  -  Privately-defined  body  parts 
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13.5  MS  attributes 

The  IPM  MS  provides  more  flexible  access  to  the  general  attributes  (see  clause  A.8,  table  43,  enhanced 
column)  as  well  as  supporting  IPM  attributes  (see  dause  A.10). 

IPM  UAs  can  make  use  of  either  the  Basic  MS  or  the  IPM  MS. 

Clause  A.10  is  to  be  read  in  accordance  with  annex  C  or  Recommendation  X.420  (1988). 

An  IPM  MS  requires  support  from  both  the  General  Attributes  and  IPM  Attributes  as  specified  in  clauses  A.8 
and  A.10,  respectively. 

13.5.1      Implementation  of  the  IPM  MS  with  1984  systems 

While  the  Message  Store  is  part  of  the  1 988  MIHS  standards,  implementation  of  MS  services  with  a  1 984  MTA 
is  possitrfe.  In  order  to  interoperate  with  other  1984  MHS  systems,  implementations  with  this  configuration 
should  adhere  to  the  following  guidelines: 

a)  The  UA  must  generate  1984  P2  PDUs; 

b)  The  UA  must  identify  the  content  protocol  as  integer  2  to  the  MS; 

c)  The  MS  must  be  collocated  with  the  MTA  unless  1988  P3  support  is  provided  on  the  1984  MTA 
as  well. 

To  meet  these  guidelines,  the  UA  may  be  implemented  as  follows: 

a)  The  UA  could  conform  to  X.420  (1984),  with  1988  UA  extensions  for  utilizing  the  MS  sendees; 

b)  The  UA  could  t>e  a  1988  UA  with  restrictions  on  protocol  elements  generated  and  by  identifying 
the  content  type  as  integer  2  rather  than  22.  No  1988-specific  elements  should  be  generated. 

Details  of  the  interface  between  the  1988  MS  and  the  1984  MTA  when  collocated  are  beyond  the  scope  of 
these  Agreements. 

13.6  Body  part  conversion  functional  group 
13.6.1  General 

The  Body  Part  Conversion  Functional  Group  supports  the  functionality  required  to  perform  the  action  of 
message  body  part  conversion.  The  Element  of  Service  'Conversion  Prohibition'  is  made  mandatory  in  the 
MT  Kernel. 
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13.6.2     Elements  of  service 

The  Body  Part  Conversion  Functional  Group  provides  support  for  the  following  Elements  of  Service. 


Table  25  -  Conversion:  MT  elements  of  service 


Element  of  Service 

Support 

Conversion  Prohibition  in  Case 
of  Loss  of  Information  (1988) 
Explicit  Conversion 
Inqplicit  Conversion 

\ 
0^ 

Notes 

1    At  least  one  of  explicit  or  implicit  conversion  must 
be  supported  for  conformance  to  this  functional  group. 

Operational  Notes 

Conversions  to  and  from  General  Text  can  only  be  performed  through  implicit  conversion.  Among  possit)le 
implicit  conversions  are  the  following: 

a)  Teletex  to  General  Text; 

b)  IA5  Text  to  General  Text; 

c)  General  Text  to  Teletex; 

d)  General  Text  to  IAS  Text. 


1 13.6.3  Conformance 

An  implementation  conforming  to  this  functional  group  shall  conform  to  the  procedures  for  the  Elements  of 
Service  in  clause  13.6.2,  and  shall  obey  the  rules  defined  in  clauses  14.3.5  and  14.3.9  of  X.411  /  ISO/IEC 
I  10021-4. 

i|  The  PICS  shall  document  which  body  part  conversions  the  implementation  can  perform,  both  for  implicit 
1  and  explicit  conversion,  and  whether  "Conversion  Prohibition  in  Case  of  Loss  of  infonnation"  is  supported, 
l'  Confonnance  to  this  functional  group  does  not  mandate  conversion  between  any  two  specific  body  part 

I'  types. 

I 

I  If  conversion  has  to  take  place  and  the  Element  of  Service  "Conversion  Prohibition  in  Case  of  Loss  of 
If  Information"  is  requested,  then  the  MTA  is  not  allowed  to  perform  the  conversion  if  loss  of  information  may 

I I  occur,  according  to  the  classification  in  clause  2.1  of  X.408. 

? 

f|  If  the  General  Text  body  part  type  Is  supported,  the  implementation  must  support  two-way  conversion 
between  the  General  Text  IA5  subrepertoire  and  the  IA5  Text  body  part. 

M 

If  a  UA  is  registered  to  receive  multiple  Encoded  Information  Types  and  its  MTA  receives  a  message  for  It 
\  containing  any  of  those  registered  EITs,  the  corresponding  body  parts  shall  not  be  converted  prior  to 
\'s  delivery. 


Part  8:  Message  Handling  Systems 


December  1992  (Stable) 


13.7  Security 

There  are  no  security  requirements  to  support  IPM.  above  and  beyond  those  specifled  in  dause  10. 

13.8  Error  handling 

NOTE  -  For  further  study. 

13.9  Physical  delivery 

Table  26  specifies  the  support  for  physical  delivery  elements  of  sen/ice  as  required  by  IPM. 


Table  26  -  Physical  deNvery:  IPM  elementa  of  service 


Origination 

Reception 

Eleaent  of  Service 

(IPM  UA) 

(PDAU) 

Additional  Physical  Rendition 

§1 

0 

Basic  Physical  Rendition 

M 

Counter  Collection 

M 

M 

Counter  Collection  with  Advice 

0 

0 

Delivery  via  Bureaufaz  Service 

0 

EMS  (Express  Mail  Service) 

Ordinary  Mail 

0^ 

Physical  Delivery  Notification 

by  MHS 

0 

0 

Physical  Delivery  Notification 

by  PDS 

M 

Physical  Forwarding  Allowed 

Si 

M 

Physical  Forwarding  Pr<Aibited 

M 

M 

Registered  Mail 

0 

0 

Registered  Mail  to  Addressee 

in  Person 

0 

0 

Request  for  Forwarding  Address 

0 

Special  Delivery 

M 

Undeliverable  Mail  with  Return 

of  Physical  Message 

oi 

M 

Notes 

1    Provided  by  default            using  a  physical  delivery 

address ) . 

2    Must  support  EMS  and/or  Special  Delivery. 
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14.1  Introduction 

This  clause  specifies  the  requirements  for  an  EDI  Messaging  Service  (EDI MS).  These  requirements  are 
based  on  Recommendations  X.435  and  F.435  which  define  the  P(edi)  content  type  and  outline  various 
EDIMS  operational  scenarios. 

This  EDIMS  Implementation  Agreement  separates  the  functions  of  the  base  standard  into  a  Kemel  and 
optional  Functional  Groups  (FGs).  These  functional  groups  may  be  used  to  support  the  different  scenarios 
of  the  EDIMS. 

The  following  functional  groups  are  defined: 

-  EDIMS  Security 

-  EDIMS  Forwarding 

-  EDIMS  Multipart  Body 

-  EDIMS  Physical  Delivery 

These  agreeements  classify  the  support  of  these  functional  groups  as  follows: 


Table  27  -  EDIMS  functional  groups 


Functional  Group 

Support 

EDIMS  Forwarding 

0 

EDIMS  Security 

0 

EDIMS  Multi  Part  Body 

0 

Notes 

14.2    EDIMS  Elements  of  service 

Tables  28.1  and  29  specify  the  requirements  for  support  of  EDIMS  EoS  by  a  UA  conforming  to  the  EDIMS 
functional  group  of  this  Agreement.  The  classification  scheme  for  support  of  EoS  is  as  defined  in  clause  5.2. 
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Table  28  -  EDIMS:  Basic  EDI  elements  of  service 


Elenent  of  Service 


Orig 


Recep 


Access  Hanageaent 
Content  Type  Indication 
Converted  Indication 
Delivery  Tine  Staoqp  Indication 
EDI  Message  Identification 
Message  Identification 
Non-delivery  Notification 
Original  Encoded  Inforaation 

Types  Indication 
Submission  Time  Stamp  Indication 
Typed  Body 

User/UA  Capabilities  Registration  (1988) 


M^ 
M 


M 
M 
M 

M 
M 
M 


M-" 

M 

M 

M 

M 

M 


M 
M 

M^ 


Hotes 

1    In  the  case  of  a  collocated  UA/MTA  or  collocated 

UA/MS,  the  method  and  extent  to  which  this  Element  of 
Service  is  provided  is  a  local  matter;  it  is  not 
necessarily  testable  in  the  absence  of  support  for  the 
P3  or  P7  protocol. 
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Table  29  -  EDIMS:  OpUonal  EDI  elements  of  service 


Kernel 

Func.  Group 

Eleaent  of  Service 

HOC 

Or  1  n 

AO 
fltf 

Alternate  Recipient  Allowed 

n 

n 

Alternate  Recipient  Assignaent 

o 

Application  Security  Elesent 

f\ 
u 

oi 
u 

t>CV>— V> 

If 

n 

n 

Character  Set 

M 

M 

Content  Confidentiality 
Content  Integrity^ 

SJ 

\J 

c"' 

C 

U 

r\ 
U 

DCil»— A  f  o 

c7 

/t 
\^ 

Conversion  Prohibition 

n 

n 

Conversion  Prohibition  in  Case 

of  Information  Loss  (1988) 

f\ 

f\ 
\j 

Cross  Reference  Information 

f\ 
\j 

ur 

n 

n 

n 

Ddfarred  Deliverv 

M 

Deferred  Delivery  Cancellation 

n 

Delivery  Notification 

n 

Designation  of  Recipient  by 

Directory  Name 

r\ 
\j 

Disclosure  of  Other  Recipients 

M 

M 

DL  Expamsion  History  Ind.(1988) 

M 

DL  Expansion  Prohibited 

M 

EDI  Forwarding 

FWD 

M 

EDI  Message  Type(s) 

M 

n 

EDI  Notification  Rec[uest 

M 

M 

EDI  Stemdard  Indication 

M 

M 

EDIM  Responsibility  Forwarding 

Allowed  Indication 

M 

M 

EDIN  Receiver 

M 

FWD 

M 

M 

Expiry  Date/Time  Indication 

0 

M 

Explicit  Conversion 

Grade  of  Delivery  Selection 

M 

M 

Hold  for  Delivery 

0* 

Implicit  Conversion 

0 

M 

Incomplete  Copy  Indication 

0 

M 

FWD 

02 

Interchange  Header 

M 

M 

Latest  Delivery  Designation 

0 

Message  Flow  Confidentiality 

SEC-A,B 

Message  Origin  Authentication^ 

0 

0 

C 

Message  Security  Labelling 

0 

o 

Sec— A  f  o 

Message  Sequence  Integrity 

0 

0 

Mill  ¥  \    r\Ae^  4  TiA'f'  4  f\r\    f\Al  \  xwCtTXi 

M 

M 

Multi-Part  Body 

0 

M 

MPB 

M 

Non-repudiation  of  Content 

SEC-B 

M 

M 

Originated 

0 

0 

Non- repudiation  of  Content 

SEC-B 

M 

M 

Received 

0 

0 

Non-repudiation  of  Content 

SEC-B 

Received  Request 

0 

0 

M 

Non-repudiation  of  Delivery 

0 

0 

SEC-A,B 

c' 

C 

Non-repudiation  of  EDI 

SEC-B 

M 

Notification 

0 

0 

M 

Non-repudiation  of  EDI 

SEC-B 

M 

M 

Notification  Request 

0 

0 
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Table  29  -  EDIMS:  Optional  EDI  elements  of  service  (concluded) 


Kernel 

Func.  Group 

Element  of  Service 

Orig 

Rec 

FG 

Orig 

Rec 

Non-repudiation  of  Origin^ 

0 

0 

SEC-A, B 

C^ 

C 

Non-repudiation  of  Submission 

0 

0 

Obsoleting  Indication 

0 

M 

Originator  Indication 

M 

N 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

- 

Prevention  of  Non  Delivery 

Notification 

0 

- 

Probe 

0 

— 

Probe  Origin  Authentication 

0 

- 

Proof  of  Content  Received 

0 

0 

SEC-A, B 

M 

M 

Proof  of  Content  Received 

Request 

0 

0 

SEC-A,  B 

M 

M 

Proof  of  Delivery 

0 

0 

Proof  of  EDI  Notification 

0 

0 

SEC-A,  B 

M 

M 

Proof  of  EDI  Notification 

Request 

0 

0 

SEC-A,  B 

M 

M 

Proof  of  Submission 

Recipient  Indication 

M 

M 

Redirection  Disallowed  by 

Originator 

0 

Redirection  of  Incoming 

Messages  (1988) 

0 

Related  Message(s) 

0 

M 

Report  Origin  Authentication 

0 

0 

Requested  Delivery  Method 

M 

Restricted  Delivery  (1988) 
Return  of  Content"' 

0 

0 

Secure  Access  Management 

0 

0 

Services  Indication 

0 

0 

Stored  EDI  Message  Auto-forward 

0 

Use  of  Distribution  List  (1988) 

0 

Notes 

1    This  EOS  requires  a  bilateral  agreement. 

2    Mandatory  when  an  implementation  supports  the  removal 

of  body  parts. 

3    A  defect  report  was  submitted  to  CCITT/ISO  by  EWOS/ETSI, 

since  the  Return  of  Contents 

EoS  was  omitted  from  the 

list  of  EDIMS  EoS  in  F.435. 

4    Mandatory  if  P3  is  supported. 

5    SEC-A  or  SEC-B  EoS  may  require  the 

use  of  these 

services. 

6    SEC-B  EoS  may  require  the  use  of  this  service. 

7    Support  of  this  EOS  is  dependent  on  the  MHS  Security 

Class  implemented  to  support 

security  class  EDI- 

-A 

(SEC-A)  or  EDI-B  (SEC-B).    See  clause  10. 
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14.3    P(EDI)  protocol 

The  requirements  for  EDI-UA  support  of  the  EDI  protocol  (PedO  elements  are  defined  In  clause  A.10. 


14.4    EDIMS  Multi-Part  Body  functional  group 


14.4.1  General 

The  EDIMS  Multi-Part  Body  functional  group  defines  the  services  and  functionality  required  to  support  the 
generation  of  multiple  body  parts  in  an  EDIM.  Note  that  support  on  reception  of  Multi-Part  Body  is 
mandatory  In  the  EDIMS  Kernel. 


14.4.2     Elementa  of  aervlce 

The  EDIMS  Multi-Part  Body  functional  group  constitutes  support  of  the  following  Elements  of  Service  on 
origination: 

-  Cross  Reference  Information 

-  Multi-Part  Body 


14.5    EDI  Message  Store  (EDI-MS) 


14.5.1     MS  Attributea 


14.S  Conversion 


14.7    EDIMS  security  functional  group 

The  EDIMS  Security  functional  group  defines  the  services  and  functionality  required  to  provide  security  for 
EDIMs  and  EDINs.  These  security  features  are  specific  to  the  EDIMS.  and  are  described  in  X.435. 

As  the  interface  between  the  EDI  Messaging  (EDIMG)  user  and  the  EDI-UA  is  outside  the  scope  of  this 
document,  implementations  of  tfie  security  mechanisms  can  be  implemented  as  a  discrete 
hardware/software  component  or  witiiin  tiie  EDI-UA. 

NOTE  -  There  are  allemative  methods  of  providing  security  to  the  EDIMG  user.  For  example,  the  EDI-UA  may 
just  avaH  Itself  of  the  (content-type  independent)  security  services  provided  or  supported  t>y  the  (1968)  MHS 
and  described  in  section  10  (e.g..  content  confidentiality,  proof  of  delivery),  without  using  the  additional  sendees 
of  this  ftjnctional  group.  Finally,  security  senrioes  may  be  provided  within  the  EDI  interchange  Itself,  while 
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possibly  using  tlie  EDI  Application  Security  Element  to  convey  some  (bilaterally  agreed)  security  arguments 
(e.g.,  key  IDs)  in  the  EDIM  header. 

The  EDIMS  Security  functional  group  is  specified  as  two  security  classes,  denoted  EDI-A  and  EDI-B.  Note ! 
that  the  services  provided  below  are  provided,  in  some  cases,  by  1988  MMS  security  elements  in  the  Pi 
(and  P3)  envelope.  For  example,  depending  on  the  security  policy  in  force,  the  proof  and  non  repudiation  I 
services  Iselow  use  the  Content  integrity  Checl(  or  Message  Origin  Authentication  Check  protocol  elements. 

See  Section  10  of  these  Agreements  for  a  description  of  the  1988  MHS  Security  functional  group  and 
classes.  Annex  A  of  these  Agreements  outlines  support  of  the  security  protocol  elements  by  the  MTS. 

The  security  classes  EDI-A  and  EDI-B  need  the  Message  Origin  Authentication  and  Content  Integrity  EoS. ! 
This  shall  be  achieved  either  by  supporting  security  dass  SO.  or  any  other  security  dass  in  clause  10, 
depending  on  the  security  policy  in  force. 

\ 

NOTE  -  In  order  to  counter  the  threat  that  a  message  could  be  stolen  and  its  value  credited  to  a  third  party, 
the  use  of  content  confidentiality  is  recommended.  When  using  SOA,  the  base  security  EoS  shall  be  used  ins 
the  following  way:  \ 
the  Content  integrity  check  shall  k>e  generated  from  the  clear  content,  i 
the  Content  integrity  check  shall  be  carried  in  the  message  token;  i 
:  -        Content  confidentiality  shall  be  used.  Encryption  of  the  content  prevents  re-generation  of  the  Content 
integrity  check  by  a  third  party.  j 


14.7.1      EDIMS  security  class  EDI-A  (SEC-A) 

This  class  provides  proof  services;  the  recipient  of  an  EDI  information  object  can  be  assured  tliat  it  was 
originated  by  the  specified  EDIMG  user.  Table  29  outlines  support  for  the  EoS  contained  in  this  dass. 


14.7.2      EDIMS  security  class  EDI-B  (SEC-B)  | 

This  dass  provides  non  repudiation  services.  These  are  "stronger"  than  the  corresponding  proof  services 
in  the  sense  that  the  recipient  of  an  EDI  information  object  can  prove  to  a  third  oartv  that  the  object  was  j 
originated  by  the  specified  EDIMG  user.  Table  29  outlines  support  for  the  EoS  contained  in  this  dass. 


14.7.3      EDIMS  security  class  EDI-C  (SEC-C) 

The  security  class  EDI-C  offers  the  following  Element  of  Service: 

-  Application  Security  Element 
This  security  dass  mandates  that  the  above  service  is  provided  by  an  EDIMS  end  system. 
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14.8 


EDIMS  Physical  Delivery  functional  group 


14.9 


EDIMS  Forwarding  functional  group 


\  14.9.1 


General 


'  The  EDIMS  Forwarding  functional  group  defines  the  services  and  functionality  required  to  perform  forwarding 
i|  of  an  EDI  message  by  or  on  behalf  of  an  EDIMG  user. 


I  An  EDI-UA  or  EDI-MS  claiming  conformance  to  the  EDI  Forwarding  functional  group  shall  understand  the 
i  semantics  of  the  EDIMS  abstract  operations  and  sen/ice  with  regard  to  forwarding,  EDI  Notifications  and 
;  EDIN  reasons/diagnostic  codes.  The  EDI-UA  or  EDI-MS  shall  generate  appropriate  EDI  notifications  when 
i\  accepting,  forwarding,  or  refusing  responsibility  for  the  EDI  message.  These  notifications  may  t>e  generated 

automatically  by  an  EDI-MS  or  EDI-UA  based  on  the  presence  or  absence  of  an  EDI-MS  in  the  configuration. 
:  in  addition,  notifications  may  be  generated  as  a  result  of  a  request  by  the  EDIMG  user.  Please  refer  to 

Section  17.3.3  of  X.435  for  a  full  description  of  EDI  Forwarding. 


An  EDI-UA  that  claims  conformance  to  the  EDIMS  FonA^rding  functional  group  shall  conform  to  clause  A.  12, 
Table  47,  as  regards  protocol  elements  required  by  this  functional  group. 

14.9.2     Elements  of  service 


The  EDIMS  FonA^arding  functional  group  constitutes  support  of  the  foilowing  Elements  of  Service: 
-  EDI  Forwarding 
•  EDIN  Receiver 


^  Conditional  on  the  support  of  removal  of  body  parts,  the  EDIMS  FonA^arding  functional  group  offers  the 
additional  element  of  service: 

jl         -  Incomplete  Copy  Indication 


14.10  Use  of  Directory 
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1 5  Use  of  underlying  layers 


15.1     MTS  transfer  protocol  (PI) 

The  P1  protocol  Is  mapped  onto  the  Reliable  Transfer  Service  Element  (RTSE)  either  in  X.410-1984  mode 
or  in  normal  mode,  as  specified  in  clause  5.3.  In  X.410-1984  mode,  the  RTSE  mal<es  direct  use  of  the 
services  provided  by  the  Session  Layer,  as  specified  In  part  5  (Upper  Layers)  of  the  Stable  Implementation 
Agreements.  In  normal  mode,  the  RTSE  makes  use  of  the  services  provided  by  the  Association  Control 
Service  Element  (ACSE)  and  Presentation  Layer,  as  defined  in  part  5  (Upper  Layers)  of  these  Agreements. 


15.2    MTS  access  protocol  (P3)  and  MS  access  protocol  (P7) 

The  P3  and  P7  protocols  make  use  of  the  sen/ices  provided  by  the  Remote  Operations  Service  Element 
(ROSE),  Association  Control  Service  Element  (ACSE),  Presentation  Layer,  and,  optionally,  the  Reliable 
Transfer  Service  Element  (RTSE),  as  defined  in  part  5  (Upper  Layers)  of  these  Agreements.  It  Is 
recommended  that  RTSE  be  used  for  recovery  purposes  when  the  implementation  does  not  use  Transport 
Class  4  or  there  is  a  high  probability  of  an  association  failure. 


16  Error  handling 

This  clause  descrit>es  appropriate  actions  to  be  taken  upon  receipt  of  protocol  elements  which  are  not 
supported  in  these  Implementation  Agreements:  malformed  PDUs,  unrecognized  0/R  Name  forms,  content 
errors,  errors  in  reports,  and  unexpected  values  for  protocol  elements. 

An  imp)lementation  must  be  able  to  report  all  error  conditions  which  may  occur  with  the  appropriate  error 
information  as  defined  in  the  referenced  base  standards.  An  implementation  must  be  able  to  handle  receipt 
of  all  error  indications  which  are  defined  in  the  referenced  base  standards.  An  implementation  must  also  be 
tolerant  of  any  additional  error  indications  which  are  not  currently  defined,  but  is  not  required  to  be  able  to 
interpret  such  error  information. 


16.1     PDU  encoding 

Various  distinguished  integer  values  will  be  defined  in  future  versions  of  the  X.400  standard  that  are  not 
defined  in  the  1988  version.  When  an  unknown  distinguished  value  is  encountered  in  an  integer  or  an 
enumerated  type,  it  should,  in  general,  not  result  in  an  error.  The  value  should  be  treated  transparently  or 
ignored,  wherever  possible. 

Editor's  Note  -  it  is  intended  that  this  section  will  specif/  any  special  error  handling  required  when  unknown 
distinguished  values  are  encountered. 
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16.2  Envelope 

NOTE  -  For  further  study. 


16.3  Reports 

NOTE  •  For  further  study. 


16.4    Pragmatic  constraints 

If  an  Implementation  detects  a  pragmatic  constraint  violation,  then  it  may  generate  an  appropriate  error 
Indication  but  is  not  required  to  do  so. 


Bilateral  agreements  between  domains  may  be  implemented  in  addition  to  the  requirements  stated  in  this 
document.  Conformance  to  this  Agreement  requires  tlie  ability  to  exchange  messages  without  use  of 

il 

.'  In  order  to  achieve  a  more  precise  definition  of  conformance  requirements  according  to  the  functionality 
supported  by  an  implementation,  the  concept  of  Functional  Groups  has  been  introduced.  A  Functional 
'I  Group  is  a  set  of  related  Elements  of  Service  and  associated  protocol  elements  which  provide  a  discrete 
I  area  of  functionality. 

I  Conformance  to  this  Agreement  requires  as  a  minimum  that  all  Mandatory  Elements  of  Service  listed  in  this 
I  part  are  supported  in  the  manner  defined  in  the  MHS  standards,  as  qualified  in  this  Agreement,  for  each  of 
I  the  Functional  Groups  claimed.  Any  Optional  Elements  of  Service  for  which  support  is  claimed  must  also 
i  be  supported  as  defined  in  the  MHS  standards  and  as  qualified  in  this  Agreement.  Pragmatic  constraints 
I  shall  be  ot>served  as  specified  in  the  CCITT  X.400  (1988)  Series  of  Recommendations.  It  is  not  necessary 
!  to  implement  the  recommended  practices  of  annex  D  in  order  to  claim  conformance  to  this  Agreement. 


Confomnance  requirements  for  support  of  Functional  Groups  by  particular  configuration  types  (see  clause 
1)  are  listed  in  table  30.  An  implementation  may  claim  conformance  to  multiple  configuration  types  (e.g., 
"MTA+UA"  and  "Qass  B  MTA  only"). 


17  Conformance 


For  this  clause,  the  term  conformance  is  as  defined  in  ISO  9646. 
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Table  30  -  Conformancd  requirements 


Functional  Group 


Configuration^ 


MTA 
+2 


MTA 

+ 
MS 


MTA  Only^ 


B 


MS 
+ 

UA 


MS 
Only 


UA  Only 


P7 


P3 


MT  Kernel 
Message  Store^ 
Remote  UA 
Distribution  List 
Directory 
MH8  Management 
Security 
Redirection 
Physical  Delivery 
Other  Access  Units 
IPM  Service^ 
EDI  Service^ 


M-* 


0 

0 
* 

0 
* 
* 
* 


M 
M 

O 

o 

* 

0 
* 
* 
* 

o 
o 


M 


0 

0 
* 

o 

* 

* 
* 

o 

0 


M 
M 

o 
o 

* 

0 
* 

* 

* 

o 

0 


M 


0 

0 
* 

0 
* 

* 

* 

o 

0 


M 
* 

o 

* 

o 

* 
* 
* 


M 
- 

o 

* 

0 
* 

* 

* 

o 
o 


M 
* 

o 

* 

o 

* 
* 
* 


M 
* 

o 

* 

o 

* 
* 
* 

o! 


Notes 

1  There  are  three  conformance  classes  defined  for  the 
MT  Kernel  in  clause  17.1. 

2  Optional  elements  of  a  context-specific  UA  need  not  be 
supported  in  the  MT  Kernel  in  this  configuration,  for 
exaunple  Probe  and  Deferred  Delivery  Cancellation. 

3  The  designation  of  a  '•<-'  in  a  configuration  (e.g., 
'MTA-i-MS')  implies  that  there  is  no  exposed  protocol  in 
the  interface  between  the  two  components. 

4  There  are  two  conformance  levels  defined  in  clause 
17.2  for  MS  support. 

5  At  least  one  of  the  content-specific  functional  groups 
must  be  supported. 

6  The  content-specific  functional  groups  may  include 
reqniirements  for  levels  of  support  by  an  MS  emd/or  MTA 
(e.g.,  in  terms  of  attributes  supported,  conversion 
requirements,  etc.).  In  table  29,  the  support  of  a 
content-specific  functional  group  by  the  MS  only  implies 
support  of  the  MS  requirements  for  that  content  type 
(i.e.,  attribute).  Similarly,  support  in  the  MTA  for  a 
content-specif ic  functional  group  only  implies  support 
for  the  MTA  requirements  for  that  content  type  (e.g., 
conversion) . 


17.1     MT  Kernel  Conformance  Classes 

The  MT  Kernel  conformance  classes  are: 

a)  A  dass  "A"  MT  Kernel  implementation  conveys  a  message,  probe,  or  report  to  another  MT  Kemel 
using  standard  means.  A  class  "A"  MT  Kernel  is  specifically  implemented  in  order  to  transfer 
messages,  probes,  and  reports  which  have  previously  been  transferred  and  need  not  support 
submission  and  delivery.  A  class  "A"  MT  Kernel  nnay  perfomn  other  activities  such  as  originate 
reports,  expand  distribution  lists,  and  perform  conversions. 
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b)  A  dass  "B"  MT  Kernel  Implementation  supports  submission,  delivery,  and  transfer  using  standard 
means,  I.e..  P3  and  PI .  A  dass  "B"  MT  Kernel  need  not  support  the  transfer  of  previously  transferred 
messages,  probes,  or  reports. 

c)  A  dass  "C"  MT  Kernel  implementation  requires  support  for  transfer  of  messages,  prob>es,  and 
reports  to  another  MT  Kemel  using  standard  means.  A  class  "C  MT  Kernel  does  not  require  support 
for  the  transfer  of  previously  transferred  messages,  probes,  and  reports,  and  message  submission 
and  delivery  is  achieved  by  non-standard  means. 

An  MTA  may  conform  to  one  or  more  of  the  MT  Kernel  classes.  For  example,  a  class  "B"  or  "C"  MT  Kernel 
which  supports  the  transfer  of  previously  transferred  messages,  probes,  and  reports  is  also  confornnant  to 
a  dass  'A"  MT  Kemel.  Figure  11  illustrates  several  combinations  of  MT  Kernel  conformance  classes. 
Additional  combinations  are  possible. 


UA 


MS 


MTA 
Class  B 


MTA 
Class  A 


MTA 
Class  AB 


standard 
Non-stemdard 


MTA 
Class  C 


Figure  11  -  MT  kernel  conformance  classes 


UA 


MS 


UA 


MS 


17.2    MS  conformance  levels 

The  MS  conformance  levels  are: 

a)  A  Basic  MS  only  requires  support  for  the  General  Attributes  as  specified  in  clause  A.8,  b>asic 
column  of  table  43; 

b)  An  enhanced  MS  requires  support  for  more  of  the  General  Attributes  as  specified  in  clause  A.8 
(enhanced  cdumn); 

c)  A  Secure  MS  additionally  requires  support  for  the  attributes  as  specified  in  clause  A.9. 
For  content-specific  MS  requirements,  see  the  appropriate  content-specific  clauses. 
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17.3    EDI-UA  conformance 

The  EDI  functional  group  requires  the  support  of  the  EDIFACT  and  ANSI  XI 2  EDI  syntaxes. 


18  Management  domain  agreements 

I 

The  sections  above  describe  agreements  among  Implementors  of  particular  X.400  components  (e.g..  MTAs, 
UAs,  MSs).  There  are  some  agreements  that  don't  apply  to  a  single  X.400  component,  but  Instead  apply  to 
an  entire  domain  of  X.400  components.  This  section  details  any  requirements  for  X.400  domains, 
Independent  of  those  for  Individual  X.400  components.  A  single  X.400  component  cannot  be  conformance 
tested  for  these  domain  requirements,  but  for  a  domain  to  daim  to  be  'operationally  OIW  compliant,"  it  must 
abide  by  the  rules  stated  below. 


18.1    Management  domain  names 

This  section  contains  requirements  on  matters  being  considered  by  the  U.  S.  CCITT  Study  Group  D  for 
rational  decisions.  Such  decisions  are  lilceiy  to  supersede  the  relevant  portions  of  this  clause. 

The  Implementation  Agreements  for  1 984-based  MHS  implementations  requires  that  all  Management  Domain 
Names  (tx>th  Private  and  Administration)  shall  be  unique  within  the  United  States.  This  is  also  a  requirement 
for  1988-based  MHS  Implementations. 

A  "Construction  Syntax"  is  defined,  which  uses  a  registered  OSI  Organization  Name  from  the  ANSI  US 
Register  of  Organization  Names  as  a  "root"  In  the  construction  of  MHS  Management  Domain  Nanws  e.g., 
ADMD  and  PRMD).  The  constructed  combinations  based  on  this  "root"  will  be  guaranteed  to  be  unique,  and 
thus  be  safely  used  as  MHS  MD  names  in  the  United  States.  Other  countries  may  wish  to  adopt  these  same 
rules. 

MHS  MD  (PRMD  and  ADMD)  names  shall  be  constructed  according  to  the  Extended  BNF  grammar  shown 
In  figure  12. 


<ADMDNaiBe>  : :  -  <MDNa]ne> 

<PRMDN2une>  : :  =  <MDNane> 

<MDName>  : : = 

<NationalOrganizationName>  j 

<ConstcuctedNeune>  | 

<Nat  ionalOrgani  zat  ionNumbeo 

<ConstructedNaine>  s:  = 

<Nat  ionalOrgami  zat  ionName>  "-i-  ''<Organi  zat  ionallyDeterminedPart> 

Figure  12  -  Management  domain  name  construction 
Sut)ject  to  all  of  the  following  rules: 
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Rule  1.  The  entire  <MDName>  must  not  exceed  16  bytes  (Including  any  constructor  operators  that 
may  be  included,  and  shall  be  composed  entirely  of  PrintableString  characters. 

Rule  2.  The  <NationalOrganizationName>  shall  be  drawn  from  the  alphanumeric  names  registered 
In  the  US  Register,  it  shall  contain  at  least  one  non-numeric  character,  and  not  contain  the 
constructor  operator (plus  sign). 

Rule  3.  Each  <NationalOrganizationName>  obtained  from  the  US  Registry  will  be  accompanied  by 
a  Numl)erForm  (numeric  value)  which  shall  be  bound  as  the  <  NationaiOrganizatlonNumber  >  to  the 

<  NatlonalOrganizationName  > . 

Rule  4.  In  a  <ConstructedName>.  the  <OrganizationallyDeterminedPart>  shall  be  certified  to  be 
unique    under   the    <  NationalOrganizationName>    (sub)authority.    by  the 

<  NatlonalOrganizationName  >  registration  authority. 

Rule  5.  A  <NationalOrganizationNumber>  shall  be  obtained  from  the  US  Register  and  bound  to  the 

<  ConstructedName  > . 

Rule  6.  A  Private  Management  Domain's  PrivateDomainidentlfler  shall  be  the  same  as  its 
PrivateDomainName. 

NOTES 

1  The  PRMD  names  resulting  from  the  <  ConstructedName  >  syntax  (those  having  a "+"  in  them)  are  atomic 
values  from  the  point  of  view  of  the  MIA  -  in  particular,  it  is  not  permissible  for  the  MIA  to  route  on 
components  of  the  PRMD  name. 

2  The  construction  rules  are  such  that  if  ABC  is  a  Registered  National  Organization  Name,  then  the  ovtmer  of 
that  name  controls  the  MHS  Domain  Name  space  including  "ABC  and  "ABC +< anything >,"  but  not 
"ABC  <  anything  >." 

3  A  *+'  Is  legal  in  an  ANSI  provided  name. 

4  If  a  Registered  Organization  Name  already  contains  the  construction  operator  ("+'  sign),  then  in  order  to 
use  the  name  as  an  <  MDName> ,  its  owner  must  also  register  the  "root"  which  precedes  the  first "+ "  sign,  with 
the  US  Register  of  Organization  Names,  (e.g.,  company  B+Z+P  vwuld  need  to  register  "B"  to  be  able  to  use 
the  "constructed"  name  of  B+Z+P.) 

5  For  the  special  case  of  the  construction  operator  ("+"  sign)  being  the  first  character  of  a  Nationally 
Registered  Name,  no  special  action  is  required  beyond  its  normal  registration  with  the  US  Registry  of 
Organization  Names. 

6  If  the  sub-authority  determined  by  <  NatlonalOrganizationName  >  so  wishes,  the 
<OrganlzationallyDeterminedPart>  can  be  constructed  using  rules  similar  to  the  aboye,  resulting  in  a 
hierarchical  construction  separated  by  "+"s.  In  particular,  the  sub-authority  must  maintain  its  own  registry  and 
might  (for  example)  define  the  <OrganizationallyDeterminedPart>  using  the  syntax 
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<OrganizationallyDeteriBinedPart>  <DivisionNaine> 

I     <DivisionName>  "■¥'*  <DivisionallyDeterminedPart> 

Figure  13  -  Name  conatruction  by  subauthorities 

where  the  <DMsionName>  is  drawn  from  the  sub-authority's  registry  (and  does  not  contain  a  '+").  Thus 
the  sub-authority  can  deiegate  the  use  of  the  prefix 


<Nat  ionalOrgani  zat  ionNa]ne>-t-<Di  vi  8  ionNa]ne> 

Figure  14  -  Prefix 

to  someone  else. 


18.2    Use  of  ADMD  names 

This  subsection  was  developed  by  an  X.400  SIG  worl<ing  group  in  April,  1990.  It  contains  extremely 
controversial  positions  that  invol<e  national,  commercial,  and  quality  of  service  issues.  The  OIW  may  not  be 
the  correct  forum  to  make  these  national  decisions.  Until  these  decisions  can  be  reached  or  a  national  forum 
established,  this  section  renr^ins  as  a  placeholder  in  the  OIW  X.400  SIG  Worl<ing  Text  document  only. 

NOTE  -  Version  2  of  the  CCITT  X.400  Implementors  Guide,  dated  16  March  1990,  allows  for  a  single  zero  ('0*) 
character  as  the  ADMD  name  for  the  case  of  a  PRMD  that  is  not  reachable  from  any  ADMD.  The  following 
discussion  does  not  apply  to  such  PRMDs. 

A  PRMD  may  be  directly  connected  to  more  than  one  ADMD.  Since  a  PRMD  may  not  alter  the  originators 
ORAddress,  the  Country /ADMD  name  pair  provided  in  the  Originator  ORAddress  may  not  match  those  of 
the  first  ADMD  to  receive  the  message  from  the  PRMD.  The  first  ADMD  is  required  to  accept  such  messages 
and  may  not  eilter  the  originator's  ORAddress. 

Any  message  originated  by  a  PRMD  must  have  an  Originator's  ORAddress  that  either  uses  the  single  space 
ADMD  name  or  uses  a  Country /ADMD  name  pair  for  an  ADMD  to  which  the  PRMD  is  connected.  (In  both 
cases  the  Country  name  is  required.) 

The  X.400  Recommendations  have  defined  a  mechanism  that  enables  PRMDs  connected  to  multiple  ADMDs 
to  enter  a  single  space  as  the  ADMD  name.  To  support  this,  these  agreements  recognize  two  classes  of 
ADMDs.  ADMDs  in  the  first  class,  "space-supporting"  ADMDs,  must  be  abUe  to  route  on  PRMD  name, 
independently  from  the  ADMD  name.  Furthermore,  the  space-supporting  ADMDs  must  arrange  their  routing 
configuration  such  that  all  PRMDs  are  reachable  from  all  ADMDs.  PRMDs  using  the  single  space  ADMD 
name  must  be  connected  to  at  least  one  space-supporting  ADMD. 

ADMDs  in  the  other  class,  "non-space-supporting"  ADMDs,  must,  at  a  minimum,  route  messages  for  which 
the  ADMD  name  is  a  single  space  to  a  space-supporting  ADMD  (in  the  indicated  country).  It  is  hoped  that 
in  the  long  term,  all  ADMDs  will  be  able  to  route  on  the  PRMD  name  when  the  ADMD  name  is  a  single 
space. 
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18.3    Uniqueness  of  MTS  Identifiers  within  a  management  domain 


[when  generating  an  lASString  in  an  MTS  Identifier,  each  MTA  in  a  domain  must  ensure  that  the  string  is 
j  unique  within  the  domain.  This  shall  be  done  by  providing  an  MTA  designator  with  a  length  of  12  octets 
[Which  is  unique  within  the  domain,  to  be  concatenated  to  a  per  message  string  with  maximum  length  of  20 
'loctets. 

[Two  pieces  of  information,  the  MTA  name  and  MTA  designator,  need  to  be  registered  within  an  MD  to 
guarantee  uniqueness.  This  registration  facility  need  not  be  automated.  If  the  MTA  name  is  less  than  or 
equal  to  12  characters,  it  Is  recommended  that  it  also  be  used  as  the  MTA  designator. 
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Annex  A  (normative) 

MHS  protocol  specifications 

Tables  31  through  48  specify  the  requirements  for  support  of  Ml-iS  protocol  elements  for  conformance  to 
this  Agreement.  It  should  be  noted  that  the  tables  specify  minimum  support  for  conformance  to  the  relevant 
Kernel  functional  groups  and  where  appropriate  also  specify  enhanced  support  requirements  where  one  or 
more  further  functional  groups  are  claimed.  All  element  support  is  subject  to  further  review  and  may  be 
upgraded  in  later  versions  of  this  Agreement. 

Within  the  classification  tables  (32-48),  the  column  "S"  indicates  the  classification  from  the  base  standards. 
This  is  provided  for  reference  purposes  only  and  is  intended  to  be  in  agreement  with  the  base  standards. 

The  protocol  support  classification  scheme  used  in  this  version  of  this  Agreement  is  described  below. 
However,  it  should  be  noted  that  the  scheme  is  currently  under  review  both  within  the  OIW  X.400  SIG 
and  in  the  EWOS/ETSI  MHS  groups  and  is  likely  to  be  revised  for  later  versions  of  this  Agreement. 

The  classification  of  support  for  a  protocol  element  specifies  the  requirements  for  implementations 
conforming  to  this  Agreement  to  be  able  to  generate,  receive  and  process  that  protocol  element,  as 
appropriate  (the  "receiving"  role  includes  relaying  where  appropriate).  The  classification  of  support  for  each 
protocol  element  is  relative  to  that  for  its  containing  element.  Where  sub-elements  within  a  containing 
element  are  not  listed,  then  their  support  classification  shall  be  assumed  to  be  that  of  the  containing 
element.  Where  the  range  of  values  to  be  supported  for  an  element  is  not  specified,  then  all  values  defined 
in  the  base  standard  shall  be  supported. 

The  classifications  have  been  revised.  The  former  classifications  relate  to  the  classifications  in  Part  7  of  the 
Stable  Agreements  as  shown  in  table  31. 


Table  31  -  Classification  changes 


Former 
Category 

New 

Originator 
Category 

Recipient 
Category 

Generatable  (G) 
Supported  (H) 
Mandatory  (M) 
Required  (R) 
Unsupported  (X) 

Mandatory  (M) 
Optional  (0) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

The  support  classifications  are  stated  for  both  Origination  and  Reception  (0/R)  in  the  following  tables  (32- 
48).  The  defined  support  for  each  is  stated  within  each  classification. 

Implementations  conforming  to  this  Agreement  must  be  capable  of  accepting  the  syntax  of  every  protocol 
element  of  a  protocol  for  which  support  is  claimed.  When  an  MS  or  MTA  receives  a  protocol  element  that 
according  to  the  base  standard  should  be  conveyed  to  another  MHS  entity  (MTA,  MS,  or  UA),  the  MS  or 
MTA  is  required  to  preserve  the  semantics  of  that  protocol  element  in  the  PDU  conveyed.  Notwithstanding 
the  above,  criticality  must  be  observed  according  to  the  base  standard. 
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Mandatory  (M)  on  Origination:  Implementatkxis  conforming  to  this  Agreement  shall  generate  this 
element  in  all  information  oi3jects  in  which,  according  to  the  base  standards,  it  shall  occur. 

Mandatory  (M)  on  Reception:  implementations  conforming  to  this  Agreement  shall  process  this 
element  appropriately  according  to  its  semantics. 

Optional  (O)  on  Origination:  Where  this  element  is  not  conveyed  from  one  MHS  entity  to  another, 
implementattons  conforming  to  this  Agreement  may  optionally  be  capable  of  generating  this 
protocol  element,  but  are  not  required  to  do  so. 

Optional  (O)  on  Reception:  implementations  conforming  to  this  Agreement  may,  but  are  not 
required  to  be  capable  of  processing  this  protocol  element 

NOTE  -  Some  protocol  elements  may  not  be  conveyed,  if  downgrading  rules  are  applied. 

To  Be  Detennined  (*):  the  support  classification  for  this  protocol  element  has  yet  to  be  determined. 

Not  Applicable  (-):  The  protocol  element  is  not  applicable  in  the  particular  context  according  to  the 
base  standard. 

Where  the  dynamic  behavior  of  protocol  elements  need  to  be  specified,  the  following  classification  scheme 
is  used: 

Mandatory  (m):  The  protocol  element  shall  always  be  implemented  and  generated.  On  reception, 
correct  action  shall  be  taken  as  specified  in  the  base  standard,  or  as  qualified  or  specified  in  tfiese 
Agreements.  Absence  of  the  corresponding  protocol  element  shall  cause  the  appropriate  abstract 
error  to  t>e  generated. 

Excluded  (x):  The  protocol  element  shall  not  be  present  or  it  must  be  possible  to  prevent  its  use. 
Its  presence  shall  cause  the  appropriate  ak)stract  error  to  be  generated. 

Dynamic  conformance  classifications  are  Indicated  in  a  single  column  of  each  of  the  Protocol  Element 
tables.  The  classification  applies  to  the  usage  only  of  the  protocol  elements  which  have  a  static  classification. 

There  are  two  types  of  tables  defining  support  for  protocol  elements:  the  first  is  a  base  table  that  contains 
and  classifies  all  protocol  elements,  and  the  second  is  a  delta  table  for  a  functional  group. 

Functional  group  tables  need  only  list  those  protocol  elements  for  which  the  functional  group  has  cfuinged 
the  support  requirements  from  the  base  table.  Additional  containing  constructor  elements  may  be  listed  in 
order  to  provide  context  information. 

If  the  functional  group  changes  the  support  requirements  for  a  given  element  it  must  be  classified  in  the 
delta  table.  Changes  should  only  place  more  restrictions  on  the  required  support,  for  example  changing 
an  optional  element  to  be  either  mandatory,  excluded,  or  out  of  scope.  If  an  element  in  the  delta  table  is 
not  classified,  it  is  only  listed  for  context  information  and  the  required  support  for  it  is  the  same  as  its 
classification  in  the  base  table. 

The  Dynamic  column  is  only  filled  in  if  the  profile  changes  the  requirements  for  use  of  the  element  In  every 
PDU.  for  example,  if  support  for  the  element  is  required,  but  use  of  the  element  is  optional  in  a  given  PDU. 
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However,  if  you  are  supporting  a  functional  group  that  element  will  always  (or  never)  be  used. 

A.1      MTS  transfer  protocol  (P1) 

Within  Table  32,  the  columns  under  "Support  by  MT  Kernel  Class'  refer  to  the  MT  Kernel  Conformance 
Classes  defined  in  clause  17.1. 
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TabI*  32  -  ClaMlflcatlon  of  th«  Pi  protocol  •lomontt 


MTS  Transfer  Protocol  (PI) 

Part    1  of  9 

Support  by  MT  Kernel  Claa 

IS 

C<»ments/Reference8 

B/C 

A 

Protocol  Elenent 

o 
O 

O/R 

0/R 

See  Note  1 

Operations 

MTABind 

H 

Iff  /iff 

n/H 

M/M 

MTABind 

MTAunbina 

H 

iff  /Iff 

M/M 

MTSE 

MessageTransfer 

N 

iff  /iff 
M/M 

M/M 

ProbeTransfer 

u 

n 

iff  /iff 
M/M 

M/M 

ReportTransfer 

n 

iff  /iff 
M/M 

M/M 

See  Note  7 

Arguments/Results 

MTABind 

ARGUMENT 

<NULIi> 

0 

O/M 

O/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

initiator-naae 

M 

M/M 

M/M 

initiator-credentials 

M 

M/M 

M/M 

si^le 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

secur  i  ty— context 

U 

O/U 

RESUiiT 

\j 

u/n 

O/M 

See  Note 

2 

<SET> 

0 

M/M 

M/M 

responder-nane 

n 

U  /If 

M/M 

M/M 

r esponde  r — c  r  edent  i  al s 

n 

M/M 

simple 

u 

Iff  /iff 

M/M 

M/M 

strong 

0 

0/0 

0/0 

MTS-APDU 

■essage 

M 

M/M 

O/M 

envelope 

M 

M/M 

M/M 

MessageTransferEnvelope 

content 

M 

M/M 

M/M 

probe 

M 

M/M 

O/M 

ProbeTransferEnvelope 

report 

M 

M/M 

M/M 

envelope 

M 

M/M 

M/M 

ReportTranscerEnvelope 

content 

M 

M/M 

M/M 

Repor t Trans ferContent 

MessageTr  ems £erEnvelope 

M/M 

message- i  dent  i  £  i  er 

M 

M/M 

MTSIdentiCier 

originator-name 

M 

M/M 

M/M 

ORName 

or  i  g  inal-encoded-informat  ion- 

types 

0 

M/M 

0/0 

Encodedlnformat  ionTypes 

content-type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

1  external 

0 

O/M 

0/0 
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Table  32  ■>  ClassHication  of  tha  PI  protocol  alamenta  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    2  of  9 

Support  by  MT  Kernel  Class 

Comments/References 

o/y^ 

A 

e 
o 

ft/p 

n/p 

U/K 

See  Note  1 

o 

n/n 

w/ 

M/M 

n/M 

V//  n 

All  values 

r\ 
yj 

n/n 

ft/M 

^  4  aol  /^aii  TCk^^^ ^T€St^i      An^  a 

UX  O  WX        lAX  13~%/L*L         X^X  OllV  B 

o 

w 

O/M 

O/M 
w/  n 

XIUL/X  A  W  JL  W     V»wU  W  L  B  X  wU"UX  Wll  X  U  X 

n 

V 

M/M 

O/M 

w/  r* 

di1  ^oi^nA^ o_i*o^  1  ni  An^ «s  1  1  oua^^ 

\j 

M/M 

n/n 

^^n^  An  4*      A^  ti  i*n_^  Ami  AG  ^ 

wwU  U 9311 V ~  X  ^  v>  U X  U~ X  6\^Ul3B  c 

ft /ft 

n/n 

Ha^A1*1*aHm^a1  1  \7  a  1*  17_  4*  1  mA 

uox ox  X ou^uvx  X  vox  xims 

ft 

ft/n 

n/n 

£>ox  *Gioiiiclxii*~x/X  xauoxax~ 

X  UX  WX  JUCI  I*  X  V/II 

ft 

n/n 

PerDomainBilaterallnfo 

^x  Awo~XUXv^xilleH>  Xv,?U 

M 

M/M 

M/M 

n/n 

Tracelnformation 

Ana  4 

ft 

M/M 

n/n 

M  /M 

n/n 

ExtensionField 

v A/*<  4  ni  An'f' — 1"  AAGQ 1  rrnniAn^  « 

X  JS\^  X^X  dll#~X  OQBB  X  ^IXIUOIA  ir" 

pxv/iix JJX  cou 

ft 

M/M 

n/n 

M/M 

n/n 

H 1  .A imAno  4  ^n_TM*^h  i  1^4  ^  aH 

UX~0  JL^CIllB  X  Wll*~^X  \Jik  X  1/X  C  V»U 

ft 

M/M 

n/  n 

n/Vi 
yjf  n 

WWU  WX  B  X  V11**WX  lirIi~Xv^BB~ 

ft 

O/M 

O/M 

1      Afl^  «»Ha1  i  vAfv— ^  i  niA 

o/o 

o/o 

w/  w 

See  X.411,  14.1.1  note  2 

wx  X ^  X ua  i>v/x  ~x  w  ux ii^ciuux  cbb 

ft 

o/o 

o/o 

w/  v_/ 

fir  4  a  A  nafrf^r— PArfr  "i  f  "i  a 

wX  X      X  UO  ItfVi/X  *^V^OX      X  X  X  WCI  CO 

ft 

o/o 

o/o 

oonfr  Anfr-»or%nf  i  H Ant*  i  a  1  i  ^ \7. 

\^^AA  COIA  V^WVi/AlX  X  UOil  C  X  CIX  X  J 

A 1  rtr>f  1  "hhin— 1  H  Anf*  i  f  i  ai* 
cix^v^x  X  i»ixiu~ X  uoii u  X  X  X ox 

ft 

M/M 

M/M 

n/  n 

See  Note  6 

inAaaAnAuf^i* 4  nA  n_ 

AUOBBCl^O"~wX  X  ^  X  Il~ 

clU  uliOiiu  X       c  X  v.^Xl*diodv 

ft 

ft /ft 

ft /ft 
\J/\J 

niAQfi ArrA— a A/**ii f*  j  ^\r.l  aVvaI 

lUOBBCI^O^BOV^UX  X  Vj^*"XClX#OX 

ft 

n/n 

n/n 

See  Note  5 

fi  A^ll  1*  4      X7_TV^1  A              A  14  An 4*  4  f  4  AT* 

BOwux  X  i. j^~^/^x  X        X  uoli i«  X  X  X ox 

ft 

M  /M 

n/n 

M/M 

n/n 

Q A011 1* 4  4* ace4  ^4^a^4  nn 
bowux  X  (»j^^wxciBB  XXX      u  xvu 

ft 

M  /M 

n/n 

M/M 

n/  n 

nv*  4             mA  vlr 
^x  X  vawjf  ~iucix  fw 

ft 

n/n 

n/n 

V^/ 

secur  i  ty-cat egor  i  es 

0 

M/M 

M/M 

content -cor relator 

0 

0/0 

0/0 

dl-expans ion-history 

0 

O/M 

O/M 

DLExpans  ionHi  s  tory 

internal-trace-information 

0 

M/M 

M/M 

InternalTracelnfo 

per-recipient-f ields 

M 

M/M 

M/M 

r ec i p i en t -name 

M 

M/M 

M/M 

ORNeune 

originally-specified- 

r ec i p i en t -numbe r 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

explicit-conversion 

0 

0/0 

0/0 

extensions 

0 

O/M 

O/M 

ExtensionField 

originator-requested- 

alternate-recipient 

0 

0/0 

0/0 

r  eques  ted-delive  r y-me  t  hod 

0 

M/M 

O/M 

physical-forwarding- 

prohibited 

0 

0/0 

0/0 

physical-forwarding-address- 

r eques t 

0 

0/0 

0/0 

phy s  ical-deliver  y-mode  s 

0 

0/0 

0/0 
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Table  32  -  Classification  of  the  Pi  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 


Part    3  of  9 


Support  by  MT  Kernel  Class 


Protocol  Element 


S 


B/C 
0/R 


A 
0/R 


Comment  s /Re  f e  r ences 


See  Note  1 


registered-mail-type 
recipient-number-for-advice 
E^iysical-rendit  ion-attributes 
jj^ysical-deli  very-report- 
request 
message-token 
asyame t  r  i  c- token 
signature-algorithm- 
identifier 

name 
time 

sign-data 
content -conf  i  dent  i  al i  ty- 

algor  i  t hm- i  dent  i  f  i  e  r 
content-integr  i  ty-check 
message-security-label 
proof-of-deli very-request 
message-sequence-number 
encrypt  ion-algor  i  thm- 

identif ier 
encrypted-data 
cont ent-conf  i  dent  i  al i  ty-key 
content-integr  i  ty-check 
message-security-label 
content-integrity-key 
mes  sage-s  equence-nximbe  r 
content-integr  i  ty-check 
pr  oof -of -de  1  i  ve  r  y- r  eques  t 
redi  r ec t  i  on-hi  story 

ProbeTrans  f  erEnvelope 

probe-i  dent  i  f  i  er 

originator-name 

or  i  g  i  nal-encoded- i  nf orma t  i  on- 
types 

content-type 
built-in 
external 

content-identif ier 

content-length 

per-message-indicators 
disclosure-of -recipients 
implicit-conversion-prohibited 
alternate-recipient-allowed 
content-return-request 

per-domain-bi lateral- 
information 


0/0 
0/0 
0/0 

0/0 
0/0 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
0/0 
M/M 
0/0 

M/M 
M/M 
M/M 
M/M 
0/0 
0/0 
0/0 
M/M 
M/M 
0/M 


M/M 
M/M 

M/M 
M/M 
M/M 
0/M 
0/M 
M/M 
M/M 
0/0 
M/M 
M/M 
0/0 

0/0 


0/0 
0/0 
0/0 

0/0 
0/0 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
0/0 
M/M 
0/0 

M/M 
M/M 
M/M 
M/M 
0/0 
0/0 
0/0 
M/M 
M/M 
0/M 


M/M 
M/M 

0/0 
M/M 
0/0 
0/0 
0/0 
0/0 
0/M 
0/0 
0/M 
0/0 
0/0 

0/0 


See  Note  5 


See  Note  6 
See  Note  6 


MTSIdentifier 
ORName 


Encodedinf ormat ionTypes 


PerDomainBi laterallnfo 
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Table  32  -  Classification  of  the  PI  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    4  o£  9 

Support  by  MT  Kernel  Clat 

18 

Comments/References 

B/C 

A 

Protocol  Element 

8 

0/R 

0/R 

See  Note  1 

t r ace- i nforma t i on 

M 

M/M 

M/M 

Tracelnformation 

extensions 

0 

M/M 

M/M 

ExtensionField 

recipient-reassignment- 

prohibited 

0 

0/0 

0/0 

dl-expans ion-prohibited 

0 

M/M 

0/M 

conver s  ion-wi  th-loss- 

prohibited 

0 

0/0 

0/0 

originator-certificate 

0 

0/0 

0/0 

message-secur  i  ty-label 

0 

0/0 

0/0 

content-correlator 

0 

0/0 

0/0 

probe-or  i  gi n-au thent  i cat  ion- 

check 

0 

0/0 

0/0 

dl-expans ion-history 

0 

0/M 

0/M 

DLExpansionHistory 

internal-trace-information 

0 

M/M 

M/M 

InternalTracelnfo 

per-recipient-f ields 

M 

M/M 

M/M 

recipient -name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

r  ec  i  p  i  en  t  -nvimbe  r 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

expl i  c  i  t -conve  r  s  i  on 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

originator-requested— 

alternate-recipient 

0 

0/0 

0/0 

r eque s t ed -de 1 i ve r y-me t hod 

0 

M/M 

0/M 

physical-rendition-attributes 

0 

0/0 

0/0 

redirection-history 

0 

0/M 

0/M 

ReportTrauisferEnvelope 

report-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

repor t-des  t  inat  ion-name 

M 

M/M 

M/M 

ORName 

trace- information 

M 

M/M 

Traceinf ormat  ion 

extensions 

0 

M/M 

M/M 

ExtensionField 

message-secur  i  ty-label 

0 

0/0 

0/0 

or  i  g  i  na t or -and-DL-exp«ms  i  on- 

OriginatorAndDL 

history 

0 

M/M 

0/0 

Expans i onHi s t or y 

repor t i ng-DL-name 

0 

0/0 

0/0 

report ing-MTA-certificate 

0 

0/0 

0/0 

report-origin-authentication- 

check 

0 

0/0 

0/0 

internal-trace-information 

0 

M/M 

M/M 

InternalTracelnfo 

Repor tTransferContent 

subject-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

subject-intermediate-trace- 

information 

0 

M/M 

M/M 

Tracelnformation 

or iginal-encoded-informat ion- 

types 

0 

M/M 

M/M 

Encodedinf ormat  ionTypes 
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Table  32  -  Classification  of  th«  Pi  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    5  of  9 

Support  by  MT  Kernel  Class 

Comment  s /Re f e  r ence s 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

content— type 

o 

M/M 

n/n 

Duiit— m 

O 

W  /if 

n/n 

n/n 

external 

u 

M/M 

n/n 

con  t  en  t — 1  den  1 1  £  1  e  r 

O 

n/n 

n/n 

returned— content 

o 

U/n 

\j/\j 

audi tionai—inrormat ion 

Q 

U/KJ 

O/O 

extensions 

O 

O/M 

O/M 

ExtensionField 

content -cor relator 

0 

O/M 

O/M 

per— recipient— fields 

n 

W  /if 

M/M 

n/n 

actual-recipient-name 

M 

M/M 

M/M 

ORNeune 

originally-specif ied- 

r ec i pi en t -numbe r 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

last— trace— information 

n 

n/n. 

M/M 

arrival-time 

n 

n/n 

n/n 

con ve  r  t  ed-encoded- 

informat  ion-types 

0 

M/M 

M/M 

Encodedinf ormat ionTypes 

report 

w 

n 

M/M 

M/M 

delivery 

O 

M/M 

O/O 

message-delivery-time 

0 

M/M 

M/M 

type— ot—MTS— user 

u 

M/M 

U/U 

non— ae  x i ve  ry 

u 

M/M 

M/M 

non-delivery-reason-code 

0 

M/M 

M/M 

non-delivery-diagnostic- 

code 

0 

O/M 

O/M 

originally-intended-recipient- 

njune 

o 

n/n 

W  /If 

M/M 

ORNeune 

supplementary-information 

0 

0/0 

0/0 

extensions 

0 

M/M 

M/M 

ExtensionField 

redirection-history 

0 

M/M 

M/M 

RedirectionHi story 

physical-forwarding-address 

0 

0/0 

0/0 

recipient-certificate 

0 

0/0 

0/0 

proof -of -deli very 

0 

0/0 

0/0 

Coimnon  Data  Types 

Encodedinf ormat  ionTypes 

bu  i 1 1 - i  n-encoded- i  nf ormat  i  on- 

types 

M 

M/M 

M/M 

See  Note  3 

non-bas  i  c-pa  r  2une  t  e  r  s 

0 

0/0 

0/0 

external-encoded-inf ormat ion- 

types 

0 

O/M 

O/M 

MTSIdentif ier 

global-domain-identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

local-identifier 

M 

M/M 

M/M 
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Table  32  -  Classification  of  the  PI  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    6  of  9 

Support  by  MT  Kernel  Clat 

IS 

C<»ments/References 

n  //^ 

o/K, 

A 

rrococox  cxeinenc 

5 

U/K 

0/R 

See  Note  1 

FerDomainBi laceraixnro 

count  ry-name 

H 

M/M 

M/M 

aain  inisicraci  on— aomci  i  n— naiiie 

If  /If 

n/n 

M/M 

DoaainNeune 

pr  i  vat  e— dona  i  n—  i  dent  i  £  i  er 

o 

n/M 

M/M 

D<»ainName 

(only  encoded  as  SEQ  if 

both  present) 

bilateral-information 

M 

M/M 

M/M 

X  racexnroriHab  xon 

Traceinf ormat  ionElenent 

H 

M/M 

M/M 

QXODax— oomain— ident 1 t ler 

M 

M/M 

M/M 

Globa IDoma i nl den t i f i e r 

aona  i  n— suppx  i  ea— i  nrorinac  i  on 

M 

If  /if 

M/M 

M/M 

srri  vax— c  me 

u 

n 

M/H 

M/M 

routing-action 

M 

M/M 

M/M 

relayed 

0 

M/M 

M/M 

V*  A  ^        1  ^  A  i4 

r\ 
U 

f\  /If 

n/if 

a  V  V  eiup  u  ea— aomci  i  n 

r\ 
\J 

A  /If 

0/M 

GlobalDomainldentif ier 

uvJLoc  L       u  line 

If  /If 

n/n 

M/M 

con ve  r  c  ea— encoaea— 

inf ormat  ion-types 

0 

0/M 

0/M 

Encodedinf ormat ionTypes 

other -act ions 

0 

0/M 

0/M 

redirected 

0 

0/M 

0/M 

dl-operation 

0 

0/M 

0/M 

ExtensionField 

type 

M 

M/M 

M/M 

criticality 

0 

0/M 

0/M 

for-submission 

0 

0/0 

0/0 

for-tremsfer 

0 

M/M 

M/M 

for-delivery 

0 

M/M 

M/M 

value 

M 

M/M 

M/M 

DLExpems  ionHi  story 

DLExpemsion 

M 

M/M 

M/M 

ORAddressAndOpt  ionalDi  rectory 

Neune 

M 

M/M 

M/M 

ORNeune 

d  1  -exp2ms  i  on- 1  i  me 

M 

M/M 

M/M 

i 

r 
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Table  32  -  Classification  of  tha  PI  protocol  elamants  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    7  of  9 

Support  by  MT  Kernel  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

InternalTracelnformation 

InternalTracelnformat ionEleuent 

n 

n/n 

n/n 

g lobal -doma i n- i den t i £ i e r 

M 

M/M 

M/M 

GlobalDomainldentif ier 

mta-name 

M 

M/M 

M/M 

mta-suppl i  ed-in£ormat  ion 

M 

M/M 

M/M 

arrival-time 

M 

M/M 

M/M 

routing-action 

M 

M/M 

M/M 

relayed 

0 

M/M 

M/M 

rerouted 

0 

0/M 

0/M 

attempted 

0 

mta 

0 

0/M 

0/M 

domain 

0 

0/M 

0/M 

GlobalDomainldentif ier 

deferred-time 

0 

0/M 

0/M 

converted-encoded-information 

-types 

0 

0/M 

0/M 

Encodedinf ormat ionTypes 

other-actions 

0 

0/M 

0/M 

redirected 

0 

0/M 

0/M 

dl-operation 

0 

0/M 

0/M 

Or  i  g  i  na t or AndDLExpans  i  onHi  story 

M/M 

M/M 

originator-or-dl-neune 

M 

or  i  g  i  nat  i  on-or -expans  i  on- 1  ime 

M 

M/M 

M/M 

RedirectionHi story 

Redirection 

M 

M/M 

M/M 

i  n t  ended- r  ec  i  p  i  en t -name 

M 

M/M 

M/M 

ORAddressAndOptionalDi rectory 

Name 

M 

M/M 

M/M 

ORNeune 

redi  rect  ion-t  ime 

M 

M/M 

M/M 

redirection-reason 

M 

M/M 

M/M 

ORName 

address 

M 

M/M 

M/M 

standard-attributes 

M 

M/M 

M/M 

count  ry-ncune 

0 

M/M 

0/M 

Count ryName 

admi  n  i  s  t  r  a  t  i  on-doma  i  n-name 

0 

M/M 

0/M 

DomainNfune 

network-address 

0 

M/M 

0/M 

terminal-identifier 

0 

M/M 

0/M 

pr  i  vat  e-doma  i  n-neune 

0 

M/M 

0/M 

DomainNeune 

organi  zat  ion-name 

0 

M/M 

0/M 

numeric-user-identifier 

0 

M/M 

0/M 

personal-neune 

0 

M/M 

0/M 

surnaune 

M 

M/M 

0/M 

given-name 

0 

M/M 

0/M 

initials 

0 

M/M 

0/M 

See  Note  4 

gener at  i  on-gual i  f  i  er 

0 

M/M 

0/M 

o r gam  i z a t i ona 1 -un i t -name s 

0 

M/M 

0/M 
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Table  32  -  Classification  of  the  Pi  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    8  of  9 

Support  by  MT  Kernel 

Class 

Comment  s /Refer ences 

B/C 

A 

Protocol  Element 

s 

0/R 

0/R 

See  Note  1 

Orgeuii  zat  ionUni  tName 

M 

M/M 

0/M 

domain-defined-at tributes 

0 

H/H 

0/VL 

Doma i nDe £ i nedAt t r i bu t e 

M 

K/Vl 

o/a. 

tvpe 

M 

M/M 

M/M 

value 

M 

H/k 

M/M 

extension-attributes 

0 

0/k 

0^ 

ExtensionAttr ibute 

comaon-neune 

0 

0/M 

0/M 

t  e  1  et  ex— common— neune 

0 

0^ 

0/M 

teletex-organization-neune 

0 

M/M 

0/M 

teletex-personal-ncune 

0 

M/M 

0/M 

teletex-organi  zat  ional-uni  t- 

names 

0 

M/M 

0/M 

teletex-domain-def ined- 

attributes 

0 

M/M 

0/M 

pds-neune 

0 

O/M 

0/ii 

phys  i  cal-del i  very-count  ry- 

name 

0 

0/M 

0/M 

postal-code 

0 

O/M 

0/M 

phys  ical-deli  ve  r  y-o£  £  i  ce-neune 

0 

0/M 

0/M 

phys  i  cal-del ivery-o££  i  ce- 

number 

0 

0/M 

0/M 

ex t  ens  i  on-OR-add  r  es  s - 

components 

0 

0/M 

0/M 

phys  i  ca 1 -de 1 i  ve  r y-pe  r  sonal- 

naune 

0 

0/M 

0/M 

physical-delivery- 

organi  zat  ion-neune 

0 

0/M 

0/M 

extension-physical-delivery- 

address-components 

0 

0/M 

0/M 

un£ormatted-postal-address 

0 

0/M 

0/M 

street— address 

o 

O/M 

O/M 

post-o££ice-box-address 

0 

0/M 

0/M 

poste-restante-address 

0 

0/M 

0/M 

un  i  que-pos  t  a  1 -ncune 

0 

0/M 

0/M 

local-postal-attributes 

0 

0/M 

0/M 

extended-network-address 

0 

0/M 

0/M 

terminal-type 

0 

0/M 

0/M 

di  rectory-name 

0 

0/0 

0/0 

Ext ens  i  onAt  t  r  i  bu t  e 

extension-attribute-type 

M 

M/M 

M/M 

ext ens  ion-at  t  r  ibute- value 

M 

M/M 

M/M 

GlobalDomainIdenti£ier 

country-name 

M 

M/M 

M/M 

Count  ryNeune 

admi  nistrati  on-doma  i  n-naune 

M 

M/M 

M/M 

DomainName 

private-domain-identi£ier 

0 

M/M 

0/M 

DomainName 
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Table  32  -  Classification  of  tlie  Pi  protocol  elements  (concluded) 


MTS  Transfer  Protocol  (PI) 


Part    9  of  9 


Support  by  MT  Kernel  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Comment  s/References 


See  Note  1 


Count  ryNeune 
zl21-dcc-code 
iso-3166-alpha2-code 

DomainNeune 
numeric 
printable 


0/M 
M/M 


0/M 
M/M 


0/M 
0/M 


0/M 
0/M 


Notes 

1  The  MT  Kernel  implementation  classes  are  defined  in 
clause  17.1. 

2  The  action  to  be  taken  on  receipt  of  null  MTABind 
authentication  is  that  an  implementation  must  understand  the 
sem£uitics,  but  the  form  of  authentication  that  is  acceptable 
is  a  local  matter. 

3  An  implementation  is  only  rec[uired  to  generate  EITs  that 
correspond  to  the  body  parts  it  is  capable  of  generating. 

4  If  the  initials  component  of  personal-neune  attribute  is  used, 
it  should  comprise  all  of  the  person's  initials  (including  the 
given  name)  except  the  person's  surnaune,  as  specified  in 
X.402/IS  10021-2. 

5  All  SO  services  may  be  provided  without  using  the  message  token, 
e.g.,  using  per-message  extensions. 

6  In  secure  messaging,  use  of  elements  within  the  message  token  is 
preferred  to  use  of  equivalent  elements  in  the  subject  message 
envelope.  A  security  policy  shall  define  which  other  elements 
are  dynamically  mandated  and  shall  define  which  message  security 
labels  are  used  for  security  context  checking. 

7  In  the  absence  of  any  specific  processing  requirements  for  a 
particular  element  in  the  Message  Transfer  or  Probe  Transfer, 
the  action  to  be  taken  is  simply  the  creation  of  the 
corresponding  element  in  the  Report  Transfer  and  is  subject  to 
constraints  specified  in  X.411. 
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A.2     Interpersonal  messaging  protocol  (P2) 


Table  33  -  Classification  of  the  P2  protocol  elements 


Interpersonal  Messaging  Protocol 

(P2) 

Part  1  of  3 

Support 

Dy 

TIA 

Protocol  Element 

S 

Comments/References 

InforaationObject 

ipm 

0 

M/M 

n/  n 

IPM 

ipn 

0 

M/M 

IPN  -  see  Note  4 

TDM 

heading 

M 

M/M 

this-IPM 

M 

M/M 

IPMIdentifier 

originator 

0 

n/n 

OROescriptor 

author  i  z  ing-user s 

0 

n/M 

OROescriptor 

primary-recipients 

0 

M/M 

RecipientSpecif ier 

copy- recipients 

0 

M/M 

RecipientSpecif ier 

b 1 i nd-copy- recipients 

0 

O/M 

RecipientSpecif ier 

replied-to-IPM 

0 

M/M 

IPMIdentifier 

obsoleted-IPMs 

0 

O/M 

IPMIdentifier 

related-IPMs 

0 

n/M 

IPMIdentifier 

subject 

0 

M/M 

n/  n 

See  Note  1, 

8 

expiry-time 

0 

O/M 

reply-time 

0 

O/M 

reply-recipients 

0 

O/M 

ORDescriptor 

iniDortance 

0 

O/M 

sensitivity 

0 

O/M 

auto-forwarded 

0 

O/M 

extensions 

0 

O/M 

Head  i  ngEx t  ens  i  on 

incomplete-copy 

0 

0/0 

languages 

0 

O/M 

body 

M 

M/M 

BodyPart 

IPN 

common-fields 

M 

M/M 

subject-ipm 

M 

M/M 

ipn-originator 

0 

M/M 

ORDescriptor 

ipm-prefer red-recipient 

0 

M/M 

ORDescriptor 

conversion-eits 

0 

O/M 

Encodedinf ormat  ionTypes 

non-receipt-fields 

0 

M/M 

See  Note  5 

non-receipt-reason 

M 

M/M 

discard-reason 

0 

M/M 

auto-forward-comment 

0 

O/M 

returned-ipm 

0 

0/0 

See  Note  2 

receipt-fields 

0 

O/M 

receipt-time 

M 

M/M 
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Table  33  -  Classification  of  the  P2  protocol  alements  (continued) 


Interpersonal  Messaging  Protocol 

(P2) 

Part  2  of  3 

Support 

by 

UA 

Protocol  Element 

S 

0/R 

Comments/References 

0/M 

suppl-receipt-info 

0 

0/0 

Head  i  ngEx t  ens  i  on 

M/M 

type 

M 

value 

M 

IPMIdentifier 

user 

0 

O/M 

user-relative-identi£ier 

M 

M/M 

ORDescriptor 

formal-neune 

0 

O/M 

ORName  -  see  Note  3 

free-form-name 

0 

O/M 

See  Note  8 

t e 1 ephone -numbe r 

0 

O/M 

RecipientSpecif ier 

recipient 

M 

M/M 

ORDescriptor 

notification-requests 

0 

O/M 

reply-requested 

0 

O/M 

BodyPart 

M/M 

iaS-text 

0 

parameters 

M 

Vi/tt. 

repertoire 

0 

O/M 

See  Note  6 

data 

M 

M/M 

voice 

0 

* 

See  Note  7 

g3-facsimile 

0 

0/0 

parameters 

M 

Iff  /iff 

number-of -pages 

0 

O/M 

non-bas  ic-pareuneters 

0 

O/M 

data 

M 

M/M 

g4-classl 

0 

0/0 

teletex 

0 

O/M 

parameters 

M 

M/M 

number-of -pages 

0 

0/0 

telex-compatible 

0 

0/0 

non-basic-parameters 

0 

0/0 

data 

M 

M/M 

videotex 

0 

0/0 

pareuneters 

M 

M/M 

syntax 

0 

O/M 

data 

M 

M/M 

encrypted 

0 

* 

See  Note  7 
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December  1992  (Stable) 


Table  33  -  Classification  of  the  P2  protocol  elements  (concluded) 


Interpersonal  Messaging  Protocol  (P2) 


Part  3  of  3 


Protocol  Element 


Support  by 
UA 
0/R 


Comments/References 


message 
parameters 
delivery-time 
delivery-envelope 

data 
mixed-mode 
bilaterally-defined 
nationally-defined 
externally-defined 

par2uneters 

data 

Gene  r  a 1 Tex t Body Pa r  t 
ODA1984BodyPart 
IS06937BodyPart 
BilaterallyDef inedBodyPart 
USAPrivatelyDef inedBodyPart 


0/M 
M/M 
0/M 
0/M 

M/M 
0/0 
0/0 
0/0 
0/M 
M/M 
M/M 

0/M 
0/0 
0/0 
0/0 
0/0 


See  P3  OtherMessage 
DeliveryFields 


See  Note  10 


See  Note  9 


Notes 

1  The  ability  to  generate  the  maximum  size  subject  is  not 
required. 

2  May  only  be  included  if  specifically  requested  by  the 
originator. 

3  The  ORName  should  be  specified  v^erever  possible. 

4  The  ability  to  generate  an  IPN  is  optional  in  the  case  of 
an  implementation  in  which  a  non-receipt  condition  cannot 
occur  and  receipt  notification  is  not  supported. 

5  The  ability  to  generate  non-receipt-fields  is  optional  in 
the  case  of  an  implementation  in  which  a  non-receipt 
condition  cannot  occur  (see  note  4). 

6  Only  the  IA5  repertoire  has  to  be  supported  for  an 
ia5-text  body  part  on  reception. 

7  The  definition  of  these  body  parts  is  for  further  study  in 
CCITT  and  ISO. 

8  Only  the  IA5  subset  of  the  T.61  character  repertoire  need 
be  generated.  All  T.61  characters  should  be  supported  on 
reception. 

9  If  General  Text  is  supported,  an  implementation's  PICS  must 
identify  which  character  repertoires  can  be  generated  on 
origination  and  supported  on  reception. 

10  Any  basic  body  part  type  that  is  supported  on  reception  as 
an  integer  encoding  must  also  be  supported  as  an  object 
identifier  encoding.    Support  for  all  other  externally 
defined  body  parts  is  optional. 


Editor's  Note  -  The  draft  text  note  regarding  the  meaning  of  "support"  on  reception  was  missing  from  the 
editing  instructions. 
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A.3     MTS  access  protocol  (P3) 

NOTE  -  The  support  dassificatjons  for  the  UA,  MS  and  MTA  below  indicate  the  minimum  level  of  support 
required  by  implementations  conforming  to  ttiese  Agreements,  and  should  not  be  misconstrued  as  a 
redefinition  of  any  of  the  MHS  application  contexts. 


Table  34  -  Classification  of  tha  P3  protocol  elements 


MTS  Access  Protocol  (P3) 

Part    1  of  12 

Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

Operations 

MTSBind 
MTSUnbind 

M 
M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

MTSBind 

MSSE 

message-submission 
probe-submi  ss  ion 
cancel-deferred-delivery 
submi  ss  ion-cont  r ol 

M 
M 
M 
M 

M/- 
0/- 
0/- 
-/M 

M/M 
M/M 
M/M 
M/M 

-/M 
-/M 
-/M 
0/- 

MessageSubmission 
ProbeSubmission 
CancelDeferredDelivery 
Submi  ss  i  onCont  rol 

MDSE 

mes  sage-de 1 i  ve  r y 
report-delivery 

delivery-control 

M 
M 

M 

-/M 
-/M 

0/- 

M/M 
M/M 

0/- 

M/- 
M/- 

-/M 

MessageDelivery 
ReportDelivery 
See  Note  10 
DeliveryControl 

MASS 
register 

change-credentials 

(MTS  to  MTSuser) 
(MTSuser  to  MTS) 

M 

M 
M 

0/- 

-/M 
0/- 

M/M 

M/M 
M/M 

-/M 

0/- 
-/M 

Register 

Ch2uigeCredentials 
ChamgeCredentials 

Note  -    A  Message  Store  must 
operations  unaltered. 

pass  through  all  MSSE  2md  MASE 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    2  of  12 

Support  by: 

UA 

0/R 

MS 

0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

Ar  gximen  t  s /Res  u  1 1  s 

MTSBind 

MTS 

to  MTS  User 

ARGUMENT 

initiator— name 

M 

-/M 

-/M 

M/- 

MTS-user 

-/- 

-/- 

-/- 

MTA 

0 

-/O 

-/M 

M/- 

i  sMessageS tor e 

-/- 

-/- 

-/- 

messages-waiting 

0 

-/o 

-/o 

0/- 

initiator -credentials 

M 

-/M 

-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/o 

-/o 

0/- 

secur  i  ty-context 

0 

-/o 

-/o 

0/- 

RESULT 

responder-name 

M 

M/- 

M/- 

-/M 

MTS-user 

0 

M/- 

M/- 

-/M 

MTA 

-/- 

-/- 

-/- 

ismessagestore 

0 

M/- 

M/- 

-/M 

messages-waiting 

-/- 

-/- 

-/- 

responder-credentials 

M 

M/- 

M/- 

-/M 

simple 

0 

M/- 

M/- 

-/M 

strong 

0 

0/- 

0/- 

-/o 

MTSBind 

MTS 

User  to  MTS 

ARGUMENT 

initiator-name 

M 

M/- 

M/- 

-/M 

mTS-user 

0 

M/- 

M/- 

-/M 

mTA 

-/- 

-/- 

-/- 

i  sMessageS tor e 

0 

M/M 

M/- 

-/M 

messages-waiting 

-/- 

-/- 

-/- 

initiator-credentials 

M 

M/- 

M/- 

-/M 

simple 

0 

M/- 

M/- 

-/M 

strong 

0 

0/- 

0/- 

-/o 

secur  i  ty-context 

0 

0/- 

0/- 

-/o 

RESULT 

responder-ncuae 

M 

-/M 

-/M 

M/- 

mTS-user 

-/- 

-/- 

-/- 

mTA 

0 

-/M 

-/M 

M/- 

i  sMessageStore 

-/- 

-/- 

-/- 

mes  sages -wa  i  t  i  ng 

0 

-/o 

-/o 

0/- 

responder-credentials 

M 

-/M 

-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/o 

-/o 

0/- 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    3  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

s 

0/R 

0/R 

0/R 

Comments/References 

MAasAnASiibini  ss  i  on 

ARCUMEN'F 

An  ve  1 

M 

M/- 

M/- 

-/M 

MessageSubmi  ss  ion 

Envelope 

content 

M 

M/- 

M/- 

-/M 

RESULT 

fnAacsmA.aiiV^in^  6 ct  i  ^fi**  1  Hon^  i  ^  1  ai* 

M 

-/M 

-/M 

M/- 

MTSIdenti£ier 

message-submission-time 

M 

-/M 

-/M 

M/- 

content-ident  i  f  i  er 

0 

-/M 

-/M 

M/- 

Avf:Ans  ions 

0 

-/o 

~/o 

0/- 

rtr  4  ri4  n;it'  4  na— MTA— r'Art'  i  f  i  cat© 

0 

-/o 

-/o 

0/- 

L/X                  wX  — 9  U^lUX  SOX  WA4 

-/o 

-/o 

0/- 

ProbeSubmi SS ion 

ARGUMENT 

envelope 

M 

M/- 

M/- 

-/M 

ProbeSubmi ss ion 

Envelope 

RESULT 

nrnbA— siibmi  ss i on— i dpnt"  1  f  ipr 

WW     0  H  i  rill  1  0  O  X  ^^AA      X  U ^  X  L  X  ^  X 

M 

-/M 

-/M 

M/- 

MTSIdenti£ier 

nrobe—submi  SS  ion— t  line 

M 

-/M 

-/M 

M/- 

con  t  ent — i  dent  i  £  i  e  r 

0 

-/M 

-/M 

M/- 

Cance 1 De  £ e  r  r  edDe livery 

ARGUMENT 

message-submi  ss  ion-i  dent  i  £  ier 

M 

M/- 

M/- 

-/M 

MTSIdenti£ier 

SubmissionControl 

ARGUMENT 

controls 

M 

-/M 

-/M 

M/- 

See  Note 

1 

restrict 

0 

-/M 

-/M 

0/- 

permi  ss  ible-oper at  ions 

0 

-/M 

-/M 

0/- 

permissibl e-max  i mum-con t en t - 

length 

0 

-/M 

-/M 

0/- 

permissible-lowest-priority 

0 

-/M 

-/M 

0/- 

permi  ss  ible-secur  i  ty-context 

0 

-/o 

-/o 

0/- 

RESULT 

waiting 

M 

M/- 

M/- 

-/M 

See  Note 

2 

wa  i  t  i  ng-ope  rati  ons 

0 

0/- 

0/- 

-/M 

waiting-messages 

0 

0/- 

0/- 

-/M 

wai  t  ing-cont ent-types 

0 

0/- 

0/- 

-/M 

waiting-encoded- information- 

types 

0 

0/- 

0/- 

-/M 

Encodedlnformat  ionTypes 
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Table  34  -  Classification  of  tlie  P3  protocol  stomsnts  (continued) 


NTS  Access  Protocol  (P3) 

Part    4  of  12 

Support  by: 

UA 

0/R 

MS 

0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

MessageDelivery 

ARGUMENT 

envelope 

M 

-/M 

-/M 

M/- 

MessageDeliveryEnvelope 

content 

M 

-/M 

-/M 

M/- 

RESULT 

recipient-certificate 

0 

0/- 

0/- 

-/o 

proof -of -del i very 

0 

0/- 

0/- 

-/o 

ReportDelivery 

ARGUMENT 

envelope 

M 

-/M 

-/M 

M/- 

Repor tDel i veryEnvelope 

returned-content 

0 

-/M 

-/M 

0/- 

DeliveryControl 

ARGUMENT 

controls 

M 

M/- 

M/- 

-/M 

See 

Note  3 

restrict 

0 

0/- 

0/- 

_/M 

peraissible-operations 

0 

0/- 

0/- 

-/M 

permissibl e-max  i  mum-cont ent - 

length 

0 

0/- 

0/- 

-/M 

permi  ss  ible-lowes t-pr  ior  i  ty 

0 

0/- 

0/- 

-/M 

pemissible-content-types 

0 

0/- 

0/- 

-/M 

permi ss ible-encoded- 

inforoat ion- types 

0 

0/- 

0/- 

-/M 

Encodedinf ormat  ionTypes 

permi  ss  ible-secur  i  ty-cont ext 

0 

0/- 

0/- 

-/o 

RESULT 

waiting 

M 

-/M 

-/M 

M/- 

See 

Note  4 

wa  i  t  i  ng-ope  r  a  t  i  ons 

0 

-/M 

-/M 

0/- 

wa  i  t  i  ng-mes  sages 

0 

-/M 

-/M 

0/- 

wai  t  ing-content-types 

0 

-/M 

-/M 

0/- 

wa i  t  i ng-encoded- i nf orma t  i on- 

types 

0 

-/M 

-/M 

0/- 

Encodedinf ormat  ionTypes 

Register 

See 

Note  5 

ARGUMENT 

user-neune 

0 

0/- 

0/- 

-/o 

See 

X.411, 

8.4.1.1.1.1 

user-address 

0 

0/- 

0/- 

-/o 

del i verable-encoded- 

informat ion- types 

0 

0/- 

M/- 

-/M 

Encodedinf ormat ionTypes 

de 1 i  ve r abl e-max  i mum-content - 

length 

0 

0/- 

M/- 

-/M 

default-delivery-controls 

0 

0/- 

0/- 

-/M 

restrict 

0 

0/- 

0/- 

-/M 

5  . 


1 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continugd) 


MTS  Access  Protocol  (P3) 

Part    5  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

permissible-operations 

0 

0/- 

0/- 

-/M 

permissible-maximum-content- 

length 

0 

0/- 

0/- 

-/M 

permissible-lowest-priority 

0 

0/- 

0/- 

-/M 

permissible-content-types 

0 

0/- 

0/- 

-/M 

permi  ss  ible-encoded- 

informat ion-types 

0 

0/- 

0/- 

-/M 

Encodedlnformat  ionTypes 

deliverable-content-types 

0 

0/- 

M/- 

-/M 

labels-emd-redi  rect  ions 

0 

0/- 

0/- 

-/o 

user-secur  i  ty-label 

0 

0/- 

0/- 

-/O 

recipient -assigned-alternate- 

recipient 

0 

0/- 

0/- 

-/O 

ChamgeCredentials 

MTS  to  MTSuser 

ARGUMENT 

old— credent ials 

M 

-/M 

-/M 

M/- 

Note  8 

simple 

0 

-/M 

-/M 

0/- 

strong 

0 

-/O 

-/O 

0/- 

new-credentials 

M 

-/M 

-/M 

M/- 

Note  8 

simple 

0 

-/M 

-/M 

0/- 

strong 

0 

-/o 

-/O 

0/- 

ChamgeCredentials 

MTSuser  to  MTS 

ARGUMENT 

old-credentials 

M 

M/- 

M/- 

-/M 

Note  8 

SlIupX6 

KJ 

0/- 

0/- 

-/M 

Strong 

0 

0/- 

0/- 

-/o 

new-credentials 

M 

n/- 

n/- 

_/M 

Note  8 

simple 

0 

0/- 

0/- 

-/M 

strong 

0 

0/- 

0/- 

-/o 

MessageSubmi ss ionEnvelope 

M/- 

-/M 

See  Note 

6 

originator-nauae 

M 

M/- 

ORNcune 

or  iginal-encoded-informat ion- 

types 

0 

M/- 

M/- 

-/M 

Encodedlnformat  ionTypes 

content-type 

M 

M/- 

M/- 

-/M 

built-in 

0 

0/- 

M/- 

-/M 

external 

0 

0/- 

M/- 

-/M 

content-identifier 

0 

0/- 

M/- 

-/M 

priority 

0 

M/- 

M/- 

-/M 

All  values 

per-message-indicators 

0 

M/- 

M/- 

-/M 

disclosure-o£-recipients 

0 

0/- 

M/- 

-/M 
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Table  34  -  Clatsification  of  tha  P3  protocol  alamanta  (continued) 


MTS  Access  Protocol  (P3) 

Part    6  of  12 

Support  by: 

UA 
0/R 

HS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

iaplicit-conversion-prohibited 

0 

M/- 

M/- 

-/M 

alternate-recipient-allowed 

0 

M/- 

M/- 

-/M 

content-return-request 

0 

0/- 

M/- 

-/M 

deferred-del i  very-t  ime 

0 

M/- 

M/- 

-/M 

extensions 

0 

M/- 

M/- 

-/M 

r ec i pi ent- r eas s i gnment- 

pr^ibited 

0 

0/- 

M/- 

-/M 

dl-expans ion-prohibited 

0 

M/- 

M/- 

-/M 

conversion-with-loss- 

prohibited 

0 

0/- 

M/- 

-/M 

latest-deli very-t ime 

0 

0/- 

M/- 

-/M 

originator-return-address 

0 

0/- 

M/- 

-/M 

originator-certificate 

0 

0/- 

0/- 

-/O 

content -conf  i  dent  i  al i  ty- 

algor i t hm- i dent i f i e r 

0 

0/- 

0/- 

-/o 

message-origin- 

au t hent  i  ca t  i  on-check 

0 

0/- 

0/- 

-/o 

message-security-label 

0 

0/- 

0/- 

-/o 

proof-of-submiss ion-request 

0 

0/- 

0/- 

-/o 

content -correlator 

0 

0/- 

M/- 

-/M 

forwarding-request 

0 

0/- 

0/- 

-/M 

MS  Abstract  Service  only 

PerRecipientMessageSubmission 

Fields 

M 

M/- 

M/- 

-/M 

recipient -name 

M 

M/- 

M/- 

-/M 

ORName 

originator-report-request 

M 

M/- 

M/- 

-/M 

exDl i  ci  t— conver s  ion 

0 

0/- 

M/- 

-/M 

extensions 

0 

M/- 

M/- 

-/M 

originator-requested- 

alternate-recipient 

0 

0/- 

0/- 

-/o 

requested-deli very-method 

0 

M/- 

M/- 

-/M 

Note  9 

physical-forwarding- 

prohibited 

0 

0/- 

M/- 

-/M 

E^ysical-forwarding-address- 

request 

0 

0/- 

0/- 

-/o 

I^ys ical-del i very-modes 

0 

0/- 

0/- 

-/o 

registered-mail-type 

0 

0/- 

0/- 

-/o 

recipient -number-for-advice 

0 

0/- 

0/- 

-/o 

I^ys  ical-rendi  t  ion-at t r  ibutes 

0 

0/- 

0/- 

-/o 

{^ys  ical-del i very-report- 

request 

0 

0/- 

0/- 

-/o 

message- token 

0 

0/- 

0/- 

-/o 

content-integrity-check 

0 

0/- 

0/- 

-/o 

proof-of-deli very-request 

0 

0/- 

0/- 

-/o 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    7  of  12 

Support  by: 

Tf  & 

no 

MTA 

c 

D 

^/  Mlllll  AT^  4"  O  /DA^A1*An^AO 

C  A  A               ^  A  £ 

oee  Mo^e  d 

^  «•  4  ^  i  n  s  V  ^NT*  n  Skin  A 

M 

1*1 

M/- 

M/- 

-/M 

UKMame 

typ©s 

n 

n/- 

M/- 

-/M 

fincoQeu  xnEomiciT. xoixxy^/es 

con  c  611  u  ~  c  y 

M 

M/- 

M/- 

-/M 

built— in 

r\ 
U 

O/- 

M/- 

-/H 

excernax 

f\ 
\J 

0/- 

M/- 

-/M 

conb6nL~iQ6iiu  1 L  ler 

n 

0/- 

M/- 

-/M 

content— length 

r\ 
U 

M/— 

M/- 

-/M 

per— inessaye~muicai,OL  s 

n 

M/- 

M  / 

M/- 

-/n 

xmpx  1  ci  u— wQiiveL  a luii— p^v^ii x i^i  uisu 

o 

M/- 

M/- 

-/M 

alternate— recipient— allowed 

u 

O/- 

M/- 

-/fa 

n 
\j 

M/- 

M/- 

-/M 

recipient-reassignment- 

prohibited 

0 

O/- 

n/- 

-/n 

ux— expaiio Iv^ll— pXvJlil ui  ecu 

M/- 

M/- 

-/M 

CQUVeL  S  Ivyil— W X  Cll— XWoS  — 

n 

u/- 

M/_ 

n/- 

-/M 

or  xginaLor— cer  L  x  l  xcai.e 

n  / 
O/- 

u/- 

/n 

luessage— secuL  x     — xaoex 

n/ 
u/- 

u/- 

_/n 

-/U 

con Len b— core exacoc 

O/- 

M/- 

/M 

-/n 

probe— or  i  g  i  n— aut hent i cat i on- 

check 

0 

O/- 

U/- 

-/u 

PerRecipientProbeSubmission 

M/- 

M/- 

-/M 

Fields 

M 

recipient-name 

M 

M/- 

M/- 

-/M 

ORNeUne 

originator-report-request 

M 

M/- 

M/- 

-/M 

explicit-conversion 

0 

0/- 

M/- 

-/M 

extensions 

0 

M/- 

M/- 

-/M 

originator-requested- 

0/- 

0/- 

-/o 

alternate-recipient 

0 

r  eques  ted-deliver  y-me  t  hod 

0 

M/- 

M/- 

-/M 

See  Note 

9 

physical-rendition-attributes 

0 

0/- 

M/- 

-/M 

MessageDeliveryEnvelope 

M/- 

See  Note 

7 

message-delivery-identifier 

M 

-/M 

-/M 

MTSIdentif ler 

message-delivery-time 

M 

-/M 

-/M 

M/- 

other-fields 

M 

-/M 

-/M 

M/- 

content-type 

M 

-/M 

-/M 

M/- 

built-in 

0 

-/M 

-/M 

M/- 

external 

0 

-/M 

-/M 

M/- 

originator-neune 

M 

-/M 

-/M 

M/- 

ORNcune 
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Table  34  -  Classification  of  tha  P3  protocol  afamants  (continued) 


MTS  Access  Protocol  (P3) 

Part    8  of  12 

Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Conments/References 

or  i  g  i  nal-encoded- i  nf orma t  i  on- 

types 

0 

-/M 

-/M 

M/- 

Encodedinf oraat  ionTypes 

priority 

0 

-/M 

-/M 

M/- 

All  values 

delivery-flags 

0 

-/M 

-/M 

M/- 

i  mpl i  c i  t -conve  r  s  i  on- 

prohibited 

0 

-/M 

-/M 

M/- 

other-recipient-names 

0 

-/M 

-/M 

M/- 

ORName 

this-recipient-name 

M 

-/M 

-/M 

M/- 

0RN2U&e 

originally-intended-recipient- 

nauae 

0 

-/M 

-/M 

M/- 

ORName 

conve  r  t  ed-encoded- i  nforma t  i  on- 

types 

0 

-/M 

-/M 

M/- 

Encodedlnformat ionTypes 

message-submission-time 

M 

-/M 

-/M 

M/- 

con t  ent-identi£ier 

0 

-/M 

-/M 

M/- 

extensions 

0 

-/M 

-/M 

M/- 

conversion-wi th-loss- 

prohibited 

0 

-/M 

-/M 

M/- 

requested-deli very-method 

0 

-/M 

-/M 

M/- 

See  Note  9 

physical-forwarding- 

prohibited 

0 

-/- 

-/- 

M/- 

physical-forwarding-address- 

request 

0 

-/- 

-/- 

M/- 

phys i cal -de 1 i ve r y-modes 

0 

-/- 

M/- 

0-16 

registered-mai 1-type 

0 

-/- 

-/- 

M/- 

0-256 

recipient-number-for-advice 

0 

-/- 

-/- 

M/- 

1-32 

physical-rendition-attributes 

0 

-/- 

-/- 

M/- 

physical-delivery-report- 

request 

0 

-/- 

-/- 

M/- 

0-256 

originator-return-address 

0 

-/- 

-/- 

M/- 

originator-certificate 

0 

-/o 

-/o 

0/- 

message-token 

0 

-/o 

-/o 

0/- 

content-confidentiality- 

algor i thm- i dent i f i er 

0 

-/o 

-/o 

0/- 

content-i  nt egr  i  ty-check 

0 

-/o 

-/o 

0/- 

message-origin- 

authentication-check 

0 

-/o 

-/o 

0/- 

message-security-label 

0 

-/o 

-/o 

0/- 

proof -of -del  ivery-rec[uest 

0 

-/o 

-/o 

0/- 

redirection-history 

0 

-/M 

-/M 

M/- 

dl-expans ion-history 

0 

-/M 

-/M 

M/- 
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Table  34  -  Classification  of  tha  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    9  of  12 

Support  bys 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

Repor  t De 1 i  ve  r yEnve lope 

See  Note  7 

subject-submission-identifier 

M 

-/M 

-/M 

M/- 

MTSIdentif ier 

content-identifier 

0 

-/M 

-/M 

M/- 

content-type 

0 

-/M 

-/M 

M/- 

built-in 

o 

-/M 

-/M 

M/- 

external 

0 

-/M 

-/M 

M/- 

or  i  g  i  na 1 -encoded- i  nf orma t  i  on- 

types 

0 

-/M 

-/M 

M/- 

Encodedinf ormat ionTypes 

extensions 

0 

-/M 

-/M 

M/- 

message-secur  i  ty-label 

0 

-/O 

-/O 

0/- 

content -cor relator 

0 

-/M 

-/M 

M/- 

or  i  g  i  na t or -and-DL-expans  i  on- 

OriginatorAndDL 

history 

0 

-/M 

-/M 

M/- 

Expans i onH 1 s t or y 

r  epo  r  t  i  ng-DL-naune 

0 

-/M 

-/M 

M/- 

repor  t  i  ng-MTA-cer  t  i  f  i  ca t e 

0 

-/O 

-/o 

0/- 

r  epor  t-origin-authenticati  on- 

Check 

0 

-/O 

-/O 

0/- 

PerRecipientReportDeli very- 

/If 

-/M 

M/- 

Fields 

M 

-/M 

ac  t  ua  1  -  r  ec  i  p  i  en  t -naune 

M 

-/M 

-/M 

M/- 

ORName 

report 

M 

-/M 

-/M 

M/- 

delivery 

0 

-/M 

-/M 

M/- 

message-del ivery-t  ime 

M 

-/M 

-/M 

M/- 

type-of-MTS-user 

0 

-/M 

-/M 

M/- 

non-delivery 

0 

-/M 

-/M 

M/- 

non-delivery-reason-code 

M 

-/M 

-/M 

M/- 

non-de 1 i  ve  r y-d  i  agnos  t  i  c-code 

0 

-/M 

-/M 

M/- 

converted-encoded-informat  ion- 

types 

0 

-/M 

-/M 

M/- 

Encodedinf ormat ionTypes 

originally-intended-recipient- 

name 

0 

-/M 

-/M 

M/- 

ORNeune 

supplementary- information 

0 

-/M 

-/M 

M/- 

extensions 

0 

-/M 

-/M 

M/- 

redi  rect  ion-hi  story 

0 

-/M 

-/M 

M/- 

Redi rect lonHi story 

physical-forwarding-address 

0 

-/M 

-/M 

M/- 

recipient-certificate 

0 

-/o 

-/o 

0/- 

proof-of-delivery 

0 

-/o 

-/o 

0/- 

ORName 

MTS  user  to  MTS 

st2mdard-attributes 

country-name 

0 

M/- 

M/- 

-/M 

Count  ryNeune 

administration-domain-name 

0 

M/- 

M/- 

-/M 

DomainNeune 

network-address 

0 

M/- 

M/- 

-/M 

terminal-identifier 

0 

M/- 

M/- 

-/M 

81 


Part  8:  Message  Handling  Systems  December  1992  (Stable) 


Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part  10  of  12 

Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

pr  i  va  t  e-doma  i  n-name 

0 

M/- 

M/- 

-/M 

DomainName 

organ! zat  ion-name 

0 

M/- 

M/- 

-/M 

numeric-user-identifier 

0 

M/- 

M/- 

-/M 

personal-neune 

0 

M/- 

M/- 

-/M 

surname 

M 

M/- 

M/- 

-/M 

given-neune 

0 

M/- 

M/- 

-/M 

initials 

0 

M/- 

M/- 

-/M 

generation-qualifier 

0 

M/- 

M/- 

-/M 

orgeuii  zat  ional-uni  t-names 

0 

M/- 

M/- 

-/M 

Organi  zat  ionUni  tNaune 

M 

M/- 

M/- 

-/M 

doma i n-de f i ned-a t t r i bu t e s 

0 

M/- 

M/- 

-/M 

Doma i nDe f i nedA t t r i bu t e 

M 

M/- 

M/- 

-/M 

type 

M 

M/- 

M/- 

-/M 

value 

M 

M/- 

M/- 

-/M 

extension-attributes 

0 

M/- 

M/- 

-/M 

Extens ionAt tribute 

common-niune 

0 

M/- 

M/- 

-/M 

t  e  1  e  t  ex-common-ncune 

0 

0/- 

0/- 

-/M 

teletex-organi  zat  ion-name 

0 

0/- 

0/- 

-/M 

t e 1 e t ex-pe r s ona 1 -name 

0 

0/- 

0/- 

-/M 

teletex-organi  zat  ional-uni  t- 

neunes 

0 

0/- 

0/- 

-/M 

t  e 1 e t ex-doma  in-defined- 

attributes 

0 

0/- 

0/- 

-/M 

pds-neune 

0 

0/- 

0/- 

-/M 

phy  s  ical-deli  ve  r  y-coun  t  r  y-nsune 

0 

0/- 

0/- 

-/M 

postal-code 

0 

0/- 

0/- 

-/M 

phy s  i  cal -de 1 i  ver y-of  f  i  ce-name 

0 

0/- 

0/- 

-/M 

phys  i  cal -de 1 i  ve  r y-of  f  i  ce- 

number 

0 

0/- 

0/- 

-/M 

extens  ion-OR-address- 

components 

0 

0/- 

0/- 

-/M 

nh  vs  i  CA  T  — d©  1  i  v©  r  v  rvo  r  snn  a  1  — 

name 

0 

0/- 

0/- 

-/M 

phys  i  ca 1 -de 1 i  ve  r y- 

orgemi  zat  ion-naune 

0 

0/- 

0/- 

-/M 

extens  i  on-phy s  i  ca 1 -de 1 i  ver y- 

add r es s -component s 

0 

0/- 

0/- 

-/M 

unformatted-postal-address 

0 

0/- 

0/- 

-/M 

street-address 

0 

0/- 

0/- 

-/M 

post-off ice-box-address 

0 

0/- 

0/- 

-/M 

poste-restante-address 

0 

0/- 

0/- 

-/M 

un  i  que-pos  t  a  1  -neune 

0 

0/- 

0/- 

-/M 

local-postal-attributes 

0 

0/- 

0/- 

-/M 

extended-network-address 

0 

0/- 

0/- 

-/M 

terminal-type 

0 

0/- 

0/- 

-/M 

ORName 

MTS  to  MTS 

User 

standard-attributes 

country-name 

0 

-/M 

-/M 

M/- 

Count  ryNaune 
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Table  34  -  Classfflcation  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 


Part  11  of  12 


Support  by: 


Protocol  Element 


S 


UA 
0/R 


MS 

0/R 


MTA 
0/R 


Comment  s /Relet ence s 


adaini St rat ion-domain-name 

net%K>rk-address 

terminal-identifier 

private-domain-name 

organi  zat  ion-name 

numeric-user-identifier 

personal-neme 

surniuM 

given-ntuBe 

initials 

generat  ion-qual i  f  ier 
organi  zat  ional-uni  t-naunes 
Orgami  zat  ionUni  tName 
d^uin-def ined-attributes 
D<»ainDefinedAt tribute 
type 
value 
extens  ion-at t  r  ibut es 
common-name 
teletez-common-name 
teletex-orgemi  zat  ion-name 
teletez-personal-name 
teletex-organi zat ional-uni t- 
names 

teletex-domain-def ined- 

attributes 
pds-name 

phys  i  cal-del  i  very-count  ry-n2UBe 
postal-code 

phys  i  cal-del i very-of f  i  ce-name 

I^ysical-delivery-off ice- 
number 

extens ion-OR-address- 
coa^nents 

I^ysical-deli very-personal- 
name 

E^ysi cal-del ivery- 
organi  zat  ion-name 

extens ion-E^ys i cal-del i very- 
address-components 

unformatted-postal-address 

street-address 

post-office-box-address 

poste-restamte-address 

unique-postal-name 

local-postal-attributes 

extended-network-address 

terminal-type 


-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 

-/M 

-/M 
-/O 

-/o 
-/o 
-/o 

-/O 

-/o 
-/o 

-/O 

-/O 
-/O 

-/o 

-/O 
-/O 
-/O 

-/o 

-/O 
-/O 


-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 

-/M 

-/M 
-/M 
-/M 
-/M 
-/M 

-/M 

-/M 

-/M 

-/M 

-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 


M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 

M/- 

M/- 
M/- 
M/- 
M/- 
M/- 

M/- 

M/- 

M/- 

M/- 

M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 
M/- 


DomainName 
DomainName 


ExtensionAttribute 


83 


Part  8:  Message  Handling  Systems 


December  1992  (Stable)  ^ 


Table  34  -  Classification  of  the  P3  protocol  elements  (concluded) 


MTS  Access  Protocol  (P3) 


Part  12  of  12 


Support  by: 


Protocol  Element 


UA 
0/R 


MS 
0/R 


MTA 

0/R 


Comments/References 


Encoded  I  nformat  ionTypes 
bu  i 1 1 - i  n-encoded- i  nformat  i  on- 
types 

non-bas  i  c-par  eune  t  e  r  s 
external-encoded-informat ion- 
types 
MTSIdentifier 
g loba 1 -doma i n- i den t i f i e r 
local-identifier 
Originate  r AndDLExpans  i  onH  i  s  t  o  r y 
originator-or-dl-neune 
origination-o  r -expans  i  on- 1  i me 
RedirectionHi story 
Redirection 
intended-recipient-neune 
ORAddressAndOptionalDi rectory 
Name 

redirection-time 
redirection-reason 


M/M 
0/0 

0/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 
M/M 


M/M 
0/0 

0/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 
M/M 


M/M 
0/0 

M/0 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 
M/M 


See  Note  3 


GlobalDomainldentif ier 


ORNauae 


Notes 

1  The  MTS-user  may  interpret  any  restriction  as  simply  withhold 
*all'  submissions. 

2  No  explicit  action  needs  to  be  taken  by  the  MTA. 

3  The  MTA  may  interpret  any  restriction  as  simply  withhold  «all' 
deliveries . 

4  No  explicit  action  needs  to  be  taken  by  the  MTS-user. 

5  The  Register  operation  may  be  performed  locally  (see  X.411). 
Although  not  required  for  the  UA  for  conformance,  it  is 
considered  to  be  a  useful  service  and  support  is  recommended. 

6  The  action  to  be  taken  by  a  submitting  MTA  is  as  defined  in 
X.411  (ISO  10021-4).    In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  submission  envelope, 
the  action  to  be  taken  is  simply  the  faithful  mapping  of  such 
element  to  the  corresponding  element  of  the  appropriate  transfer 
envelope. 

7  The  action  to  be  taken  by  a  delivering  MTA  is  as  defined  in  X.41 
(ISO  10021-4).    In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  delivery  envelope,  the 
action  to  be  taken  is  simply  the  creation  of  such  element  from 
the  corresponding  element  of  the  appropriate  tramsfer  envelope. 

8  At  least  one  of  simple  and/or  strong  must  be  specified. 

9  Applies  to  ORNames  containing  Directory  Naunes  and/or  ORAddresses 
See  Recommendation  X.411,  section  8.2.1.1.1.14. 

10  In  the  absence  of  any  specific  processing  requirements  for  a 
particular  element  in  the  Message  Submission,  or  Probe  Submission, 
the  action  to  be  taken  is  simply  the  creation  of  the  corresponding 
element  in  the  ReportDelivery  (subject  to  any  constraints  specified 
in  X.411) . 

11  Applicable  only  to  reception  by  a  PDAU. 
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A.4     MS  access  protocol  (P7) 


Table  35  -  ClaMiflcation  of  the  P7  protocol  elements 


MS  Access  Protocol  (P7) 

Part    1  of  6 

Support  by: 

UA 
0/R 

MS 
0/R 

Protocol  Element 

S 

Comment  s /Re  £ e  r  ences 

Operations 

MSBind 
MSUnbind 

M 
M 

M/- 
M/- 

-/M 
-/M 

MSBind 

MSSE 

message-submission 
probe-submi  s  s  i  on 
cancel-defer  red-del i  very 

submi  ss  ion-cont  rol 

M 
M 
M 

M 

M/- 
0/- 
0/- 

-/M 

-/M 
-/M 
-/M 

M/- 

See  P3  MessageSubmission 
See  P3  ProbeSubmission 
See  P3  CancelDeferred 

Delivery 
See  P3  SubmissionControl 

MASE 
register 

change-credentials  (MS  to  UA) 
change-credentials  (UA  to  MS) 

M 
M 
M 

0/- 
-/M 
0/- 

-/M 
M/- 
-/M 

See  P3  Register 

See  P3  ChangeCredentials 

See  P3  ChangeCredentials 

MRSE 
summarize 
list 
fetch 
delete 
register-ms 
alert 

M 
M 
M 
M 
M 
M 

M/- 
M/- 
M/- 
M/- 
0/- 

-/o 

-/M 
-/M 
-/M 
-/M 
-/M 
0/- 

Summarize 

List 

Fetch 

Delete 

Regis ter-MS 

Alert 

Arguments/Results 

MSBind 
ARGUMENT 
MSBindArgument 
initiator-name 
initiator-credentials 
simple 
strong 
secur  i  ty-context 
fetch-restrictions 
allowed-content-types 
allowed-EITs 
max  i  mum-cont  ent - 1 eng t h 
MS-configurat ion-request 

M 
M 
M 
0 
0 
0 
0 
0 
0 
0 
0 

M/- 
M/- 
M/- 
M/- 
0/- 
0/- 
0/- 
0/- 
0/- 
0/- 
0/- 

-/M 
-/M 
-/M 
-/M 

-/o 
-/o 

-/M 
-/M 
-/M 
-/M 
-/M 

Opt'l  in  Basic  MS (Note  5) 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part    2  of  6 

Support  by: 

UA 
0/R 

MS 

0/R 

Protocol  Element 

S 

Conments/References 

RESULT 

MSBindResult 

M 

-/M 

M/- 

r esponde r -c r eden t i a 1 s 

M 

-/M 

M/- 

simple 

0 

-/M 

M/- 

strong 

0 

-/o 

0/- 

available-auto-actions 

0 

-/M 

M/- 

available-attribute-types 

0 

-/M 

M/- 

alert-indication 

0 

-/o 

0/- 

content-types-supported 

0 

-/M 

M/- 

Summarize 

ARGuNENT 

Summar  i  zeArgmnent 

N 

M/- 

-/M 

information-base-type 

0 

0/- 

-/M 

Inf ormat  ionBase 

selector 

M 

M/- 

-/M 

Selector 

summary-requests 

0 

0/- 

-/M 

RESULT 

Summar  i  zeResul t 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

count 

M 

-/M 

M/- 

span 

0 

-/M 

M/- 

lowest 

M 

-/M 

M/- 

highest 

M 

-/M 

M/- 

summaries 

0 

-/M 

M/- 

absent 

0 

-/M 

M/- 

present 

0 

-/M 

M/- 

type 

M 

-/M 

M/- 

value 

M 

-/M 

M/- 

count 

M 

-/M 

M/- 

List 

ARGUMENT 

ListArgument 

M 

M/- 

-/M 

information-base-type 

0 

0/- 

-/M 

Inf ormat ionBase 

selector 

M 

M/- 

-/M 

Selector 

requested-attributes 

0 

0/- 

-/M 

AttributeSelection 

RESULT 

ListResult 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

requested 

0 

-/M 

M/- 

Entrylnformation 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 


Part    3  of  6 


Support  by: 


Protocol  Element 


S 


UA 
0/R 


MS 
0/R 


Comment s /Re £e rences 


Fetch 
ARGUMENT 
FetchArgument 
information-base-type 
item 
search 
precise 
requested-attributes 
RESULT 
FetchResult 
entry-information 
list 
next 
Delete 
ARGUMENT 
DeleteArgument 
informat  ion-base-type 
items 
selector 

seguence-niunbers 
RESULT 
DeleteResult 

Register-MS 
ARGUMENT 
Reg  i  s  t  e  r -MS Ar gumen t 
auto-action-registrations 
type 

registration-identifier 
registration-parcuneter 

auto-act ion-deregist rat ions 
type 

registration-identifier 
list-attribute-defaults 
fetch-attribute-defaults 
chemge-c  redentials 
old-credentials 
new-credentials 
user-secur  i  ty-labels 
RESULT 
Regis ter-MSResult 


M/- 
0/- 
M/- 
M/- 
M/- 
0/- 

-/M 
-/M 
-/M 
-/M 


M/- 
0/- 
M/- 
M/- 
M/- 

-/M 


M/- 
0/- 
M/- 
M/- 
M/- 

0/- 
M/- 
M/- 
M/- 
M/. 
M/. 
M/. 
M/- 
O/- 

-/M 


-/M 
-/M 
-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 


-/M 

-/o 

-/M 
-/M 
-/M 

M/- 


-/M 

-/o 

-/M 
-/M 
-/M 

-/o 

-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/O 

M/- 


InformationBase 
Optional  in  Basic  MS 
AttributeSelection 

Entry Informat ion 


Informat  ionBase 
Optional  in  Basic  MS 


See  auto  action 
registration  pareuneters 


Optional  in  Basic  MS 
Optional  in  Basic  MS 
See  Note  1 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part    4  of  6 

Support  by: 

UA 
0/R 

MS 
0/R 

Protocol  Element 

S 

Comments/References 

Alert 

ARGUMENT 

Alert  Argiunent 

M 

-/M 

M/- 

alert-registration-identifier 

M 

-/M 

M/- 

new-entry 

0 

-/M 

M/- 

Entrylnformation 

RESULT 

AlertResult 

0 

M/- 

-/M 

Auto  Action  Registration 

Pareuneters 

AutoForwardRegi  s  t  rat  ionPareuneter 

filter 

0 

0/- 

-/M 

Filter 

auto- forward-arguments 

M 

M/- 

-/M 

or  i  g  inat  or-naune 

M 

M/- 

-/M 

con t  en t — i  dent  i  f  i  e  r 

0 

0/- 

-/M 

priority 

0 

0/- 

-/M 

per-message-indicators 

0 

0/- 

-/M 

See  P3  MessageSubmission 

-Envelope 

defer  red-del ivery-t  ime 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3  MessageSubmission 

-Envelope 

per-recipient-f ields 

M 

M/- 

-/M 

recipient-name 

M 

M/- 

-/M 

originator-report-request 

M 

M/- 

-/M 

explicit-conversion 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3  MessageSubmission 

-Envelope 

delete-after-auto-forwarding 

0 

0/- 

-/M 

other-parameters 

0 

0/- 

-/M 

See  Note  2 

auto-forwarding-comment 

0 

0/- 

-/M 

cover-note 

0 

0/- 

-/M 

this-ipm-pref ix 

0 

0/- 

-/M 

AutoAlertRegistrationParameter 

filter 

0 

0/- 

-/M 

Filter 

alert-addresses 

0 

0/- 

-/o 

address 

M 

M/- 

~/M 

alert-qualifier 

0 

0/- 

-/O 

requested-at tributes 

0 

0/- 

_/M 

AttributeSelection 
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Table  35  -  CiaMification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part    5  of  6 

Support  by: 

UA 
0/R 

MS 
0/R 

Protocol  Elenent 

S 

Comments/References 

C<»Bon  Data  Types 

AttributeSelection 
tvoe 
f  roa 
count 

M 

0 
0 

M/- 
0/- 
0/- 

-/M 
-/M 
-/M 

AttributeValueAssertion 
type 
value 

M 
M 

M/- 
M/- 

-/M 
-/M 

Ent rylnformat ion 
sequence-numbe  r 
attributes 
type 
values 

M 
0 
M 
M 

-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 

Filter 
item 
and 

or 
not 

0 
0 
0 
0 

M/- 
M/- 
M/- 
M/- 

-/M 
-/M 
-/M 
-/M 

Filterltem 
See  Note  3 
See  Note  3 
See  Note  4 

Filterltem 
equality 

substrings 
type 
strings 
initial 
any 
final 
greater-or-equal 
less-or-equal 
present 

approximate-match 

0 

0 
M 
M 
0 
0 
0 
0 
0 
0 
0 

M/- 

0/- 
M/- 
M/- 
0/- 
0/- 
0/- 
0/- 
0/- 
0/- 
0/- 

-/M 

-/o 

-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 
-/M 

-/o 

AttributeValueAssertion 
(Support  is  Optional  if 
0RN2une ) 

AttributeValueAssertion 
AttributeValueAssertion 

InformationBase 
stored-messages 
inlog 
out  log 

0 
0 
0 

M/- 
0/- 
0/- 

-/M 

-/o 
-/o 
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Table  35  -  Classification  of  the  P7  protocol  elements  (conduded) 


MS  Access  Protocol  (P7) 


Support  by: 


Protocol  Element 


UA 

0/R 


MS 

0/R 


Part    6  of  6 


Comments/References 


Range 

sequence -nvuEber-range 
from 

to 


creation-time- 
from 
to 

Selector 
child-entries 
range 
filter 
limit 
override 


See  Note  6 


0/- 
O/- 

O/- 

0/- 
0/- 

0/- 


OA 

o/- 
o/- 

M/. 

o/- 


-/M 
./M 
-/M 

./M 
./M 

-/M 


-/M 

./M 
-/M 
./M 
./M 


Range 
Filter 

Opt'l  in  Basic  MS-Note  5 


Notes 

1  At  least  one  of  simple  and/or  strong  must  be  specified. 

2  The  specified  syntax  of  other-par euneters  is  context-specific 
-  see  X.413  section  12.1. 

3  For  recursive  use  of  filter,  only  support  of  the  "item"  and  the 
"not"  fields  is  required;  there  is  only  one  level  of  recursion. 

4  For  recursive  use  of  filter,  only  support  of  the  "item"  field 
is  required;  there  is  only  one  level  of  recursion. 

5  If  one  of  fetch-restrictions  of  MSBind  and  override  of  Selector 
is  implemented,  the  other  must  also  be  implemented. 

6  At  least  one  of  From  or  To  must  be  implemented. 
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A.5     Classification  of  tlie  P1  protocol  elements  for  security  classes 

The  protocol  element  classifications  used  In  tables  36  and  37  should  be  viewed  as  a  delta  to  the  lower 
security  dass  or,  if  there  is  no  lower  security  class,  to  the  kernel  as  classified  in  tabUe  33.  Thus,  table  36 
shows  the  additional  support  required  in  Pi  to  conform  to  security  dass  SI .  Table  37  indicates  the  additional 
support  required  to  support  security  dass  S2  (above  and  beyond  that  for  security  dass  SI). 

NOTES 

1  There  are  no  additional  classifications  for  security  class  SO. 

2  The  addition  of  mandatory  content  confidentiality  does  not  affect  the  P1  protocol. 


Table  36  -  Conformance  classification  of  the  Pi  protocol  elements  for  security  class  81 


MTS  Tcemsfer  Protocol  (PI)  for  Security  Class  SI 

Part    1  of  2 

MT  Kernel  Static  Support  by  MTS  Class 

B/C 

A 

Protocol  Element 

0/R 

0/R 

Dyn 

Comments/References 

MTABind 

ARGUMENT 

<SET> 

initiator-credentials 

M 

simple 

0/0 

0/0 

X 

strong 

M/M 

M/M 

M 

bind- token 

M/M 

M/M 

M 

certificate 

0/0 

0/0 

secur  i  ty-cont ext 

M/M 

M/M 

M 

RESULT 

<SET> 

responder-credentials 

M 

simple 

0/0 

0/0 

X 

strong 

M/M 

M/M 

M 

bind-token 

M/M 

M/M 

M 

certificate 

0/0 

0/0 

MessageTreuis  f  erEnvelope 

extensions 

message-secur  i  t y-label 

M/M 

M/M 

M 
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Table  36  -  Conformance  classification  of  the  PI  protocol  elements  for  security  class  Si 

(concluded) 


MTS  Tr2uisfer  Protocol  (PI)  for  Security  Class  SI 


Part    2  of  2 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 

0/R 


Dyn 


Comments/References 


ReportTransferEnvelope 
extensions 
■essage-secur  i  ty-label 
per-recipient-f ields 
extensions 
aiessage-token 
asyame  t  r  i  c-token 
slgned-data 

message-secur  i  ty-label 
encrypted-data 
message-secur  i  ty-label 

bind-token 
asymme t  r  i  c-token 
s  ignature-algor  i  thm-i  dent  i  f  i  er 
naae 
tine 

signed-data 

encrypt  ion-algor  i  thin- 
identifier 

encrypted-data 
message-secur  i  ty-label 
content-integrity-key 

message-secur  i  ty-label 
security-policy-identifier 


M/M 

0/0 

M/M 
M/M 


M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 


M/M 

0/0 

M/M 
M/M 


M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 


See  Note  2 


M 


M 


See  Note  2 
See  Note  2 

See  Note  1 


M 
M 
M 
M 


M 
M 


See  Note  2 


Notes 

1  In  line  with  the  CCITT  MHS  Implementors '  Guide,  the  asymmetric 
token  cem  be  used  by  symmetric  and  asymmetric  techniques  as 
identified  by  the  algorithm  identifier. 

2  The  message  security  label  may  appear  in  any  or  all  of  the 
indicated  locations  in  the  envelope.  However  the  Security  context 
service  applies  only  to  the  label  in  the  "extensions"  and/or  token 
signed-data  as  defined  by  the  security  policy  in  force.  Labels  in  th 
token  encrypted  data  have  only  end-to-end  (UA-to-UA)  signif icemce. 
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Table  37  -  Conformance  classification  of  the  Pi  protocol  elements  for  security  class  82 


MTS  Tremsfer  Protocol  (PI)  for  Security  Class  S2 


Part    1  of  2 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Dyn 


Conent  s/Re  f  e  r  ences 


MessageTrimsferEnvelope 
extension 
originator-certificate 
certificate 
certificati  on-pa t h 
Bessage-or  i  g in-authent  i cat  ion- 
check 

algorithm-identifier 
content 

content - i  dent  i  f  i  e r 
■essage-secur  i  ty-label 

ProbeTransferEnvelope 
extensions 
originator-certificate 
certificate 
certification-path 
probe-or  i  g  in-authent  i  cat  ion- 
check 

algorithm-identifier 
con t  ent-identifier 
message-secur  i  ty-label 

ReportTremsferEnvelope 
extensions 
report ing-MTA-certificate 
certificate 
cer t  i  f  icat  ion-path 
report-origin-authentication- 
check 

algorithm- identifier 

content-identifier 

message-security-label 
per-recipient 
actual-recipient -name 
originally-intended-recipient- 
name 

delivery 
message-deli very-time 
type-of-MTS-user 
recipient-certif icate 
proof -of -del i very 

non-delivery 
non-delivery-reason-code 
non-de 1 i  ver y-d  i  agnos  t  i  c-code 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

0/0 
0/0 
M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
0/0 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

0/0 
0/0 
M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
0/0 


M 


M 


M 
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Table  37  -  Conformance  ciatsification  of  the  Pi  protocol  elements  for  security  class  S2 

(conduded) 


NTS  Transfer  Protcxsol  (PI)  for  Security  Class  S2 

Part    2  of  2 

MT  Kernel  Static  Support  by  NTS  Cl« 

ISS 
A 
0/R 

Dyn 

Comments/References 

Protocol  Element 

0/R 

Certificate 
version 
serialNumber 
signature 

algorithm 

parameters 
issuer 
validity 

notBefore 

notAfter 
subject 

subjectPublicKeylnfo 
algorithm 
sub ject Publ i  cKey 

M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

1^ 


'i 
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A.6     Classification  of  the  P3  protocol  elements  for  security  classes 

The  protocol  element  classifications  in  tatjies  38.  39.  and  40  should  be  viewed  as  a  delta  to  the  lower 
security  dass  or,  if  there  is  no  lower  security  dass.  to  the  kernel  as  dassified  in  tat)le  34.  Thus,  tatile  38 
1  shows  the  additior^  support  required  in  P3  to  conform  to  security  dass  SO.  Tatsle  39  indicates  the  additional 
||l  support  required  to  support  security  dass  Si  (above  and  t}eyond  that  for  security  dass  SO).  Tat>le  40 
Ijl  indicates  the  additional  support  required  to  support  security  dass  S2  (above  and  beyond  that  for  security 
I'j  dass  SI). 

I  NOTE  -  There  are  no  dynamic  conformance  dassifications  required  by  security  class  SO  (table  38). 


Table  38  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  SO 


NTS  Access  Protocol  (P3)  for  Security  Class  SO 

Part    1  of  2 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MessageDelivery 

RESULT 

proo£-of-delivery 

M/- 

M/- 

~/0 

MessageSubmiss  ionEnvelope 

PerRecipientMessageSubmission 

Fields 

extensions 

message-token 

M/- 

M/- 

-/o 

asymme t  r  i  c- token 

M/- 

M/- 

-/o 

s  ignature-algor  i  thin- 

identifier 

M/- 

M/- 

-/o 

name 

M/- 

M/- 

-/o 

time 

M/- 

M/- 

-/o 

signed-data 

M/- 

M/- 

-/o 

content-conf  i  dent  i  al i  ty- 

-/o 

algorithm-identifier 

0/. 

0/- 

content-integrity-check 

M/- 

M/- 

-/o 

See  Note  1 

message-security-label 

0/- 

0/- 

-/o 

proof-of-deli very-request 

M/- 

M/- 

-/o 

See  Note  1 

message-sequence-number 

0/- 

0/- 

-/o 

encrypt  ion-algor 1 thm- 

0/- 

-/o 

identifier 

0/- 

encrypted-data 

M/- 

M/- 

-/o 

content-confidentiality- 

key 

0/- 

0/- 

-/o 

content-integr  i  ty-check 

M/- 

M/- 

-/o 

See  Note  1 

message-secur  i  ty-label 

0/- 

0/- 

-/o 

content-integrity-key 

0/- 

0/- 

-/o 

message-seguence-number 

0/- 

0/- 

-/o 

content-integr  i  ty-check 

M/- 

M/- 

-/o 

See  Note  i  1 

proof-of-deli very-request 

M/- 

M/- 

-/o 

See  Note  1  | 
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Table  38  -  Conformcnee  ciastification  of  ttM  P3  protocol  elomeatt  for  MCurHy  class  SO 

(concluded) 

MTS  Access  Protocol  (P3)  for  Security  Class  SO 

Pact    2  of  2 

Static  Support  by: 

UA 

MS 

MTA 

i 

Protocol  Element 

0/R 

0/R 

0/R 

Dyn 

Comments/References 

NessageDel i veryEnvelope 

other-fields 

extensions 

■es sage- token 

-/M 

-/M 

0/- 

asynme t  r  i  c- token 

-/M 

-/M 

0/- 

s ignature-algor i thm- 

identif ier 

-/M 

-/M 

0/- 

name 

-/M 

-/M 

0/- 

time 

-/M 

-/M 

0/- 

signed-data 

-/M 

-/M 

0/- 

cont ent-conf  i  dent  i  al i  t y- 

algorithm-identif ier 

-/o 

-/O 

0/- 

content-int egr  i  ty-check 

-/M 

-/M 

0/- 

See  Note  1 

message-secur  i  ty-label 

-/o 

-/o 

0/- 

proof —of —deli very— request 

-/M 

-/M 

0/- 

See  Note  1 

message-sequence-nufflber 

-/o 

-/o 

0/- 

encrypt  ion-algor  i  thm- 

identif ier 

-/o 

-/o 

0/- 

encrypted-data 

-/M 

-/M 

0/- 

content-conf  ident  i  al i  ty- 

key 

-/o 

-/o 

0/- 

content-integrity-check 

-/M 

-/M 

0/- 

See  Note  1 

message-secur  i  ty-label 

-/o 

-/o 

0/- 

content-integrity-key 

-/o 

-/o 

0/- 

message-sequence-number 

-/o 

-/o 

0/- 

cont  ent - i nt  eg  r  i  ty-check 

-/M 

-/M 

0/- 

See  Note  1 

proof-of-deli very-request 

-/M 

-/M 

0/- 

See  Note  1 

Repor t De 1 i ve r yEnve lope 

Pe r Rec  i pi  ent Repor  tDe 1 i  ve ry- 

Fields 

extensions 

proof-of-deli very 

-/M 

-/o 

0/- 

Notes 

1    Implementations  shall  generate  no 

more  that  one  inst2mce 

of  these 

identically-named  protocol  elements  in  a  single  message. 

i! 

I 
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TabI*  39  -  Conformance  clastlflcation  of  tha  P3  protocol  alamanta  for  aacurity  claaa  Si 


MTS  Access  Protocol  (P3)  £or  Security  Class  SI 

Part    1  of  3 

Static  Support  by: 

MTA 

UA 

MS 

Protocol  Element 

0/R 

0/R 

0/R 

Dyn 

Ccwments/References 

MTSBind 

MTS  to  MTS  User 

ARGUMENT 

initiator-credentials 

M 

siaple 

-/O 

-/O 

0/- 

X 

strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/O 

-/O 

0/- 

secur  i  ty-context 

-/M 

-/M 

M/- 

M 

RESULT 

responder-credentials 

M 

simple 

0/- 

0/- 

-/O 

X 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

certificate 

0/- 

0/- 

-/o 

KTSBind 

NTS  user  to  nrs 

ARGUMENT 

initiator-credentials 

M 

simple 

0/- 

0/- 

-/o 

X 

strong 

M/- 

M/- 

-/M 

n 

bind-token 

M/- 

M/- 

-/M 

H 

certificate 

0/- 

0/- 

-/o 

secur  i  ty-context 

M/- 

M/- 

-/M 

M 

1  RESULT 

responder-credentials 

-/o 

0/- 

n 

simple 

-/O 

X 

strong 

-/M 

-/M 

M/- 

n 

bind-token 

-/M 

-/M 

M/- 

H 

1             ^'Art"  1  f  If  ate 

-/O 

-/O 

0/- 

SubmissionControl 

-/M 

M/M 

M/- 

ARGUMENT 

!  controls 

M/- 

j  permissible-security-context 

-/M 

-/M 

DeliveryControl 

M/- 

M/- 

-/M 

1  ARGUMENT 

controls 

-/M 

permissible-security-context 

M/- 

M/- 

j  Register 

ARGUMENT 

user-name 

M/- 

M/- 

-/M 

1  labels-emd-redirections 

-/M 

1  user-security-label 

M/- 

M/- 
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Table  39  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  Si  (continued) 


MTS  Access  Protocol  (P3)  for  Security  Class  SI 

Part    2  of  3 

UA 

0/R 

MS 

0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

ChangeC  r  eden t  i  a 1 s 

MTS  to  MTSuser 

ARGUMENT 

old-credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/o 

-/o 

0/- 

new-credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

Strong 

-/M 

-/M 

M/- 

n 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/O 

-/o 

0/- 

ChangeCredentials 

MTSuser  to  MTS 

ARGUMENT 

old-credentials 

M 

simple 

0/- 

0/- 

-/o 

X 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

certificate 

0/- 

0/- 

-/o 

new-credentials 

M 

u/- 

n/ 
u/- 

-/u 

Y 
A 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

certificate 

0/- 

0/- 

-/o 

HessageSubmi ss ionEnvelope 

extensions 

message-token 

M/- 

M/- 

-/M 

signed-data 

message-security-label 

M/- 

M/- 

-/M 

See  Note  1 

secur  i  t  V— tjol  i  cv— i  dent  i  f  i  er 

M/- 

M/- 

-/M 

M 

encrypted-data 

message-secur  i  ty-label 

0/- 

0/- 

-/o 

cont ent-int egr  i  ty-check 

M/- 

M/- 

-/M 

M 

message-security-label 

M/- 

M/- 

-/M 

See  Note  1 

secu  r  i  t y-pol i  cy- i  dent  i  f  i  e  r 

M/- 

M/- 

-/M 

M 

MessageDeliveryEnvelope 

extensions 

message-secur  i  ty-label 

-/M 

-/M 

M/- 

See  Note  1 

secur  i  ty-pol i  cy- i  dent  i  f  i  er 

-/M 

-/M 

M/- 

M 

message-token 

-/M 

-/M 

M/- 

signed-data 

message-security-label 

-/o 

-/O 

0/- 

See  Note  1 

encrypted-data 

message-secur i ty-label 

»/o 

-/o 

0/- 

See  Note  1 
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Tabto  39  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  Si 

(concluded) 


MTS  Access  Protocol  (P3)  for  Security  Class  SI 

Part    3  of  3 

Static  Support  by: 

UA 

0/R 

MS 

0/R 

MTA 
0/R 

Protocol  Element 

Dyn 

Comments/References 

Repor tDel i veryEnvelope 
extensions 

nessage-secur  i  ty-label 

-/M 

-/M 

M/- 

M 

See  Note  1 

bind-token 
asyamet r i c-token 
8  i  gnatur e-algor  i  thm-ident  i  £  i  er 
name 
time 

signed-data 

encrypt  ion-algor  i  thm- 
identif ier 

encrypted-data 
nessage-secur  i  ty-label 
content-integrity-key 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 

M/- 
M/- 
M/- 
M/- 

M 
M 
M 
M 

Notes 

1    The  nessage-securi ty-label  may  appear  in  any  or  all  of  the  indicated 
locations  in  the  envelope.  However,  the  security  labelling  context 
!        services  apply  only  to  the  label  in  the  "extensions"  field.  Labels  in  th 
message  token  have  only  end-to-end  (UA-to-UA)  significance. 
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Table  40 '  Conformance  classification  of  the  P3  protocol  elements  for  security  class  S2 


MTS  Access  Protocol  (P3)  for  Security  Class  S2 

Part    1  of  2 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

NTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MessageSubaission 

RESULT 

extensions 

originating-MTA-certi£icate 

-/M 

-/o 

M/- 

certificate 

-/- 

-/o 

-/- 

i  certification-path 

-/- 

-/o 

-/- 

proof -of -submi ss ion 

-/M 

-/o 

M/- 

MessageDelivery 

RESULT 

recipient— certificate 

M/- 

M/- 

-/O 

'  certificate 

M/- 

M/- 

-/M 

certification-path 

M/- 

M/- 

-/M 

Mes  s  ageSubm  i  s  s  i  onEn ve 1 ope 

extensions 

originator-certificate 

M/- 

0/- 

-/M 

certificate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

message-origin- 

authent  i  ca t  i  on-check 

M/- 

0/- 

-/M 

M 

1  rt^i*    ^Hin«4  Hon 4*  4  ^  at* 

M/_ 

n/  — 

-/n 

content 

M/- 

M/- 

-/M 

con t  ent-identifier 

M/- 

M/- 

-/M 

message-security-label 

M/- 

M/- 

-/M 

proof-of-submiss ion-request 

M/- 

0/- 

-/M 

ProbeSubmi  ss  ionEnvelope 

extensions 

originator-certificate 

M/- 

0/- 

-/M 

certificate 

-/o 

-/- 

cer t  i  f  i  cat  i  on-pat h 

-/- 

-/o 

-/- 

probe-origin-authenticat ion- 

check 

M/- 

0/- 

-/M 

M 

algor  i  thm-i  dent  i  f  i  er 

M/- 

M/- 

-/M 

cont  ent  -  i  dent  i  f  i  e  r 

M/- 

M/- 

-/M 

message-secur  i  ty-label 

M/- 

M/- 

-/M 
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I       Table  40  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  S2 

fl  (concluded) 


KTS  Access  Protocol  (P3)  for  Security  Class  S2 

Part    2  of  2 

1                          Static  Support  by: 

UA 
0/R 

MS 

0/R 

MTA 
0/R 

Dvn 

Comments/References 

Protocol  EldBient 

1  MessaQeDeliveryEnvelope 

'  extensions 

i         nriainator— certificate 

-/M 

-/M 

M/- 

certificate 

-/M 

-/M 

M/- 

certification-path 

-/M 

-/M 

M/- 

Bas saae— or i c i n— 

authentication-check 

-/M 

-/M 

M/- 

M 

1        algorithm- identifier 

-/M 

-/M 

M/- 

1  content 

-/M 

-/M 

M/- 

'        content— identifier 

-/M 

-/M 

M/- 

UIVODCkVJV     OVwU^  A  ^JT  ^%sw^ 

-/M 

-/M 

M/- 

Repor tDel i veryEnvelope 

extensions 

renort inc— MTA— cert  i  f icate 

-/M 

-/o 

M/- 

certificate 

-/- 

f 

-/o 

-/- 

cer t  i  f  i  cat  i  on— path 

-/- 

-/o 

-/- 

repor  t  —or  i  g  i  n— au t hent  i  cat  i  on- 

check 

-/M 

-/o 

M/- 

M 

PerRecipientReportDeli very- 

Fields 

extensions 

recipient-certif icate 

-/M 

-/M 

0/- 

certificate 

-/M 

-/M 

M/- 

certification-path 

-/M 

-/M 

M/- 

Certificate 

version 

-/M 

-/M 

M/- 

ij  serialNumber 

-/M 

-/M 

M/- 

i  signature 

-/M 

-/M 

M/- 

1  algorithm 

-/M 

-/M 

M/- 

1  parameters 

-/o 

-/o 

0/- 

1  issuer 

-/M 

-/M 

M/- 

1  validity 

-/M 

-/M 

M/- 

f  notBefore 

-/M 

-/M 

M/- 

1  notAfter 

-/M 

-/M 

M/- 

]  subject 

-/M 

-/M 

M/- 

i  subjectPublicKeylnfo 

-/M 

-/M 

M/- 

1  algorithm 

-/M 

-/M 

M/- 

1  subjectPublicKey 

-/M 

-/M 

M/- 

j&ble  41  presents  the  classification  delta  to  classification  tables  38, 39.  and  40.  for  the  addition  of  mandatory 
ontent  confidentiality  in  the  static  conformance  classification. 

NOTE  -  There  are  no  dynamic  conformance  classification  required  by  the  addition  of  content  confidentiality. 
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Table  41  -  Conformance  classification  of  the  P3  protocol  elements  for  security  classes  SOa,  Sla,  or  j 

S2a  ^! 


MTS  Access  Protocol  (P3)  for  Security  Classes  SOa,  Sla,  S2a 

Part    1  of  1 

Static  SuDDort  bvj 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Dvn 

CcMBments/References 

Protocol  Element 

Mes  s  aaeSuba  i  s  s  i  onEn ve 1 ooe 



extensions 

content— conf  i dent  i  al i  ty— 

algor  i  t  hfli- i  dent  i  £  i  e  r 

M/- 

0/- 

-/o 

See  Note  1 

■AS saae— token 

asvBsietric— token 

M/~ 

-/- 

_/_ 

content -conf  i  dent  i  al i  t y- 

algor i thn- i dent i f i er 

M/- 

-/- 

-/- 

See  Note  1 

encrypted-data 

content-confidentiality- 

key 

M/- 

-/- 

-/- 

1  MessageDeliveryEnvelope 

1  extensions 

1  message-token 

-/M 

-/M 

0/- 

1  asyametric-token 

1  signed-data 

-/M 

-/M 

-/- 

cont ent -conf i dent i al i ty- 

algor i tha- i dent i f i er 

-/M 

-/M 

-/- 

See  Note  1 

encrypted-data 

content-confidentiality- 

key 

-/M 

-/M 

-/- 

cont ent-conf  i  dent  i  al i  ty- 

algor  i  t hm- i  dent  i  f  i  e  r 

-/M 

-/M 

0/- 

See  Note  1 

Botes 

1    I^plenentors  shall  generate  no  more  them  one  instance  of  these 
identically  neuned  protocol  elements  in  a  single  message. 


i 

A.7     Classification  of  tlie  P7  Protocol  Elements  for  Security  Classes  \ 

\ 

The  protocol  element  classifications  in  table  42  should  be  vievved  as  a  delta  to  the  lower  security  class  or, 
if  there  is  no  lower  security  dass,  to  the  kernel  as  classified  in  table  35.  Thus,  table  42  shows  the  additional 
support  required  in  P7  to  confomi  to  security  dass  SI. 

NOTES 

1  There  are  no  additional  classifications  for  security  classes  SO  and  S2. 

2  The  addition  of  mandatory  content  confidentiality  does  not  affect  the  P7  protocol. 
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Table  42  -  Conformance  claasification  of  tha  P7  protocol  elementa  for  aecurity  ciaaa  Si 


KS  Access  Protocol  (P7)  for  Security  Class  SI 

Part    1  of  1 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MSBind 

ARGUMENT 

initiator-credentials 

M 

siople 

0/- 

-/O 

X 

strong 

M/- 

-/M 

M 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/O 

secur  i  ty-cont ext 

M/- 

-/M 

M 

RESULT 

r esponde  r -c r edent  i  a 1 s 

M 

simple 

-/o 

0/- 

X 

strong 

-/M 

M/- 

M 

bind-token 

-/M 

M/- 

M 

certificate 

-/O 

0/- 

Register-MS 

ARGUMENT 

Register-MSArgument 

cheuxgeC  r  eden  t  i  a  1  s 

-/M 

N 

old-credentials 

M/- 

M 

sinqple 

0/- 

-/o 

M 

strong 

M/- 

-/M 

X 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/o 

new-credentials 

M/- 

-/M 

M 

simple 

0/- 

-/o 

X 

strong 

M/- 

-/M 

M 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/o 

user-security-labels 

M/- 

-/M 

M 

message-security-label 

-/M 

secur  i  ty-pol i  cy-i  dent  i  f  i  er 

M/- 

M 

security-classification 

M/- 

-/M 

privacy 

0/- 

-/o 

secur  i  ty-categor  ies 

M/- 

-/M 

i 

I 


^.8     Message  store  general  attribute  support 

Table  43  specifies  tlie  classification  of  the  Message  Store  General  Attributes. 
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Table  43  -  Classification  of  the  message  store  general  attributes 


Message  Store  General  Attribute  Support 

Part  1  of  2 

Support  bys 

Bas 

Enchanced 

UA 

MS 

MS 

Attribute 

S 

R 

0 

0 

Comments/References 

chi Id-sequence-numbers 

M 

M 

M 

M 

content 

M 

M 

M 

M 

content -conf  i  dent  i  al i  ty- 

algor  i  thm- i  dent  i  £  i  er 

0 

0 

0 

0 

content-correlator 

0 

0 

0 

M 

content- i  dent  i  £  i  er 

0 

0 

0 

M 

content-integr  i  ty-check 

0 

0 

0 

0 

content-length 

0 

0 

M 

M 

content-returned 

0 

0 

0 

M 

content -type 

M 

M 

M 

M 

conversion-with-loss-prohibited 

0 

0 

0 

M 

con ve  rted-eits 

0 

0 

0 

M 

creation-time 

M 

M 

M 

M 

delivered-eits 

0 

0 

M 

M 

delivery-£lags 

0 

0 

0 

M 

d 1 -expans  ion-history 

0 

0 

0 

M 

entry-status 

M 

M 

M 

M 

entry- type 

M 

M 

M 

M 

i  nt  ended-  r  ec  i  p  i  ent  -neune 

0 

0 

0 

M 

message-delivery-envelope 

M 

M 

M 

M 

message-deli very- identifier 

0 

0 

0 

M 

message-del ivery-t  ime 

0 

0 

0 

M 

mes  sage-or  i  g  i  n-au t hent  i  ca t  i  on- 

check 

0 

0 

0 

0 

message-secur  i  ty-label 

0 

U 

U 

0 

message-submission-time 

0 

0 

0 

M 

message-token 

0 

0 

0 

0 

original-eits 

0 

0 

0 

M 

originator-certificate 

0 

0 

0 

0 

originator-ncune 

0 

0 

0 

M 

other-recipient-ncunes 

0 

0 

0 

M 

pa  rent -s  equence-numbe  r 

M 

M 

M 

M 

per-recipient-report-deli very- 

fields 

M 

M 

M 

M 

priority 

0 

0 

M 

M 

proof-of-deli very-request 

0 

0 

0 

0 

redi  rect  ion-hi  story 

0 

0 

0 

M 

report-del i very-envelope 

M 

M 

M 

M 

r epor t i ng-d 1 -name 

0 

0 

0 

M 

report ing-mta-certificate 

0 

0 

0 

0 
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Table  43  -  Classification  of  the  message  store  general  attributes  (concluded) 


Message  Store  General  Attribute  Support 

Part  2  of  2 

Support  by: 

UA 
R 

Bas 
MS 
0 

Enhanced 

Attribute 

S 

no 

0 

Comment  s/Re  £  e  r  ence  s 

report-or igin-authent  icat  ion- 
check 

security-classification 

sequence-nuaber 

sub ject-submi  ss  ion-i  dent  i  £  i  er 

this-recipient-neune 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

OOXXO 

0 
0 
M 
M 
M 

Note  -    Enhanced  MS  support  for  optional  Functional  Groups  is  for 
further  study.  Attributes  which  are  releveuit  to  these  areas  are 
currently  specified  as  Unsupported. 

li 


i 

) 
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A.9     Classification  of  tlie  MS  General  Attributes  for  Security  Classes  I 

The  classification  of  tlie  attributes  in  table  44  is  a  delta  to  the  Enhanced  MS  column  of  the  MS  General  \ 
Attributes  in  table  43.  Table  44  indicates  the  additional  attributes  that  must  be  supported  in  the  MS  for  each  j 
of  the  security  classes.  There  is  no  support  required  for  security  attributes  in  the  basic  MS.  \ 


Table  44  -  MS  security  attribute  support 


Security  Class 

Attribute 

SO 

SOa 

SI 

Sla 

S2 

S2a 

cent ent-conf  i  dent 1 al i  ty-algor  i  thm- 

identifier 

0 

M 

0 

M 

0 

M 

content-integr  i  ty-check 

M 

M 

M 

M 

M 

M 

message-secur  i  ty-label 

0 

0 

M 

M 

M 

M 

mes  sage-or  i  g  i  n-aut hent  i  cat  i  on-check 

M 

M 

M 

M 

M 

M 

message-token 

M 

M 

M 

M 

M 

M 

origination-certificate 

0 

0 

0 

0 

M 

M 

proof -of -deli very 

M 

M 

M 

M 

M 

M 

report ing-mta-certificate 

0 

0 

0 

0 

M 

M 

r epor t-or  i  g  i  n-aut hent  i  cat  i  on-check 

0 

0 

0 

0 

M 

M 

security-classification 

0 

0 

M 

M 

M 

M 
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1(110    Message  store  IPM  attribute  support 

iijabie  45  specifies  the  classification  of  the  Message  Store  IPM  attributes.  This  clause  is  to  t)e  read  In 
likccordance  with  Annex  C  of  X.420  (1988).  For  support  of  MS  General  Attrilxjtes,  see  table  43,  enhanced 
US  column. 


Table  45  -  Classification  of  the  message  store  IPM  attributes 


Message  Store  IPM  Attribute  Support 


Part  1  of  2 


Support  by: 

IPM 
UA 
R 

IPM 
MS 
0 

1 

AttriDute 

5 

 1 

CcMoients/References  | 

Suamary  Attributes: 

1 

ipm-entry-type 

0 

0 

M 

1 

ipm-synopsis 

0 

0 

M 

1 
1 

Heading  Attributes: 

1 

author i z ing-users 

0 

0 

M 

1 

auto-forwarded 

0 

0 

M 

1 

Dx 1 ua—copy ~ r ec i p i en b  s 

ft 

0 

M 

1 

copy-recipients 

0 

0 

M 

expiry-time 

0 

0 

M 

heading 

M 

M 

M 

importemce 

0 

0 

M 

i  ncomp 1 e  t  e-copy 

0 

0 

0 

languages 

0 

0 

M 

nrn-reguestors 

0 

0 

M 

obsoleted-ipms 

0 

0 

M 

originator 

0 

0 

M 

primary-recipients 

0 

0 

M 

related-ipms 

0 

0 

M 

replied-to-ipm 

0 

0 

M 

reply-recipients 

0 

0 

M 

reply-requestors 

0 

0 

M 

reply-time 

0 

0 

M 

rn-requestors 

0 

0 

M 

sensitivity 

0 

0 

M 

subject 

0 

0 

M 

this-ipm 

M 

M 

M 

Body  Attributes: 

bi lateral ly-def  ined-body- 

parts 

0 

0 

0 

body 

M 

M 

M 

enc  r ypt  ed-body-par  t  s 

0 

0 

0 

encrypted-data 

0 

0 

0 

encrypted-pareuneters 

0 

0 

0 

extended-body-part-types 

0 

0 

0 
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Table  45  -  Classification  of  the  message  store  iPIM  attributes  (concluded) 


Message  Store  IPM  Attribute  Support 

Part  2  of  2 

Support  by: 

IPM 
UA 

R 

IPM 
MS 
0 

Attribute 

s 

Comment  s /Re f e  r ences 

g3-£acs  imi le-body-par t s 

0 

0 

0 

oS—facs  imi le— data 

0 

0 

0 

g3— f acsimi le— parameters 

0 

0 

0 

g 4 —cl as s 1 — body — pa r t s 

0 

0 

0 

ia5— text— body— parts 

0 

0 

M 

ia5— text— data 

0 

0 

0 

ia5— text— parameters 

0 

0 

0 

message-body-parts 

0 

0 

M 

message-data 

0 

0 

0 

message-parameters 

0 

0 

0 

mi  xed— mode— body— par  t  s 

0 

0 

0 

na t  i  onal ly-de  f  i  ned-body-pa  r  t  s 

0 

0 

0 

t  e 1 et  ex-body-pa  r  t  s 

0 

0 

0 

teletex— data 

0 

0 

0 

teletex— Darameters 

0 

0 

0 

V  i  deot  ex-body-pa  r  t  s 

0 

0 

0 

videotex-data 

0 

0 

0 

videotex-parameters 

0 

0 

0 

voi  ce— bod V— oar  t  s 

0 

0 

0 

voice— data 

0 

0 

0 

voice-parsuneters 

0 

0 

0 

oda-1 984 -body-pa  r  t  s 

0 

0 

i  so6  9  3  7 -body-pa  r  t  s 

0 

0 

bi lateral ly-defined-body- 

parts 

0 

0 

usa-pr  i  vat ely-def  ined-body- 

parts 

0 

0 

Notification  Attributes: 

acknowledgment -mode 

0 

0 

M 

auto-forward-comment 

0 

0 

M 

con ve  rsion-eits 

0 

0 

M 

discard-reason 

0 

0 

M 

ipm-prefer red-recipient 

0 

0 

M 

ipn-originator 

0 

0 

M 

non-receipt-reason 

0 

0 

M 

receipt-time 

0 

0 

M 

returned-ipm 

0 

0 

0 

subject-ipm 

M 

M 

M 

suppl-receipt-info 

0 

0 

0 
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December  1992  (Stable) 


A.11    EDI  messaging  service  protocol  (Pedi) 


Table  46  •  Clastification  of  tha  Pad!  protocol  alamanta 


EDI  Messaging  Service  Protocol  (Pedi) 

Part  1  of  6 

Support  by  EDI 

UA 

Protocol  Element 

S 

0/R 

FGs 

0/R 

Comments/References 

1  

InfornationObject 

edim 

M 

M/M 

edin 

M 

M/M 

EDIMIdentifier 

user 

M 

M/M 

user-relative-identifier 

M 

M/M 

ExtensionField 

type 

M 

M/M 

criticality 

M 

M/M 

value 

M 

M/M 

EDIM 

heading 

M 

M/M 

body 

M 

M/M 

Heading 

M/M 

this -EDIM 

M 

originator 

0 

M/M 

recipients 

0 

M/M 

edin-receiver 

0 

0/M 

FWD 

M/M 

responsibility-forwarded 

0 

0/M 

FWD 

M/M 

edi-bodypart-tyi>e 

0 

M/M 

0/M 

incomplete-copy 

0 

0/M 

FWD 

See  Note  2 

expiry-time 

0 

0/M 

related-messages 

0 

0/M 

obsoleted-EDIMs 

0 

0/M 

edi -appl i  cat  ion-secur  i  ty- 

M/M 

elements 

0 

0/0 

SEC-C 

cross-referencing-information 

0 

0/M 

MBP 

M/M 

edi-message-type 

0 

M/M 

service-string-advice 

0 

M/M 

syntax-identifier 

0 

M/M 

interchemge-sender 

0 

M/M 

dat e-«md-t  ime-of -pr epar at  ion 

0 

M/M 

appl i  cat  ion-reference 

0 

M/M 

head  i  ng-ex t ens  i  ons 

0 

0/M 

See  Note  3 
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Table  46  -  Classification  of  ths  Pedi  protocol  elements  (continued) 


EDI  Messaging  Service  Protocol  (Pedi) 


Part  2  of  6 


Protocol  Element 


Support  by  EDI 
UA 
0/R 


FGs 


0/R 


Comments/References 


RecipientSubfield 
recipient 
action-request 

edi-noti£icat ion-requests-field 

respons  ibi 1 i  ty-pass  ing-al lowed 

interchange-recipient 

recipient-reference 

interchange-control-reference 

process  ing-pr  i or  i  ty-code 

acknowl edgemen t - r  eques  t 

conmun i ca t i ons -ag r eemen t - i d 

test-indicator 

author  i  za  t  i  on-  i  nf  orma  t  i  on 

recipient-extensions 

EDINot  i  f  icat  ionRequestsFields 
edi-notificat ion-requests 
edi-not if icat ion-security 

edi -recept  ion-secur  i  ty 


InterchangeRecipientField 
recipient-identification 
i  dent  i  f  i  ca t  i  on-code-qua 1 i  f  i  e r 
routing-address 

RecipientReferenceField 
recipient-reference 
recipient-reference-qualifier 

EDINReceiverField 
edin-receiver -name 
original-edim-identif ier 
first-recipient 

RelatedMessagesField 
RelatedMessageReference 
edi -message-reference 
external-message-reference 

EDIAppl i  cat  ionSecur  i  tyElement s- 
Field 

edi-appl icat ion-security- 
element 

edi -enc  rypted-primar y-bodypa r  t 
edi-appl icat ion-security- 
ex  tens  ions 


M/M 
0/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
0/M 


M/M 
0/0 

0/0 


M/M 
M/M 
M/M 


M/M 
M/M 


M/M 
0/M 
0/M 


M/M 
M/M 
M/M 


M/M 
M/M 

0/M 


See  Note  3 


SEC-A 
SEC-B 
SEC-A 
SEC-B 


M/M 
M/M 
M/M 
M/M 


FWD 
PWD 


M/M 
M/M 


See  Note  3 


110 


>art  8:  Message  Handling  Systems  December  1992  (Stable) 

Table  46  -  Classification  of  tha  Pedl  protocol  elements  (continued) 


EDI  Messaging  Service  Protocol  (Pedi) 


Part  3  of  6 


Protocol  Element 


Support  by  EDI 
UA 
0/R 


FGs 


0/R 


Comaents/References 


CrossReferencinglnformat ion- 
Subfield 
application-cross-reference 
■essage-reference 
body-part-reference 

ServiceStringAdviceField 
component -data-el ement - 

separator 
data-element-separator 
decimal-notation 
release-indicator 
reserved 

segment-terminator 

Syntaxidentif ierField 
synt  ax- i  dent  i  f  i  er 
syntax-version 

InterchzmgeSenderField 
sender-identif ication 
ident  i  f  i  cat  i  on-code-qual i  f  i  er 
address-for-reverse-routing 

Author  i  zat  ioninf ormat  ionField 
authorization- information 
authori zat ion- information- 
qualifier 

Body 

pr  iaiary-body-par  t 
additional-body-parts 

Pr  imaryBodyPar t 
edi -body-part 
forwarded-EDIM 

EDIMBodyPart 
pareuneters 
message-data 

MessageParameters 
delivery-time 
de 1 i  ve r y-enve 1 ope 


M/M 
M/M 
M/M 


M/M 
M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 


M/M 
M/M 
M/M 


M/M 
M/M 


M/M 
0/M 


M/M 
0/M 


0/M 
M/M 


0/M 
0/M 


MBP 


FWD 


FWD 


FWD 
FWD 


M/M 


M/M 


M/M 


M/M 
M/M 


See  Note  1 
See  Note  1 
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Table  46  -  Classification  of  tha  Padi  protocol  elements  (continued) 


EDI  Messaging  Service  Protocol  (Pedi) 

Part  4  o£  6 

Support  by  EDI 

Protocol  Element 

s 

0/R 

FGs 

0/R 

Comments/References 

other-paraaeters 

0 

0/0 

See  Note  4 

MessageData 
heading 
body 

M 
M 

M/M 
M/M 

BodyOrRemoved 
or imarv— or —removed 
addi  t  ional-body-par t s 

M 
0 

M/M 
M/M 

Pr  imaryOrRemoved 
r  emoved-ed  i -body 
pr  imary-body-par t 

0 
0 

0/M 
M/M 

See  Note  5 

Add  i  t  i  onalBodyPar t  s 
external-body-part 
place-holder 

0 
0 

M/M 
0/M 

See  No  fie  5 

EDIM-ExternallyDef inedBodyPart 
body-pa r t - r e £ e r ence 
external-body-part 

0 
M 

M/M 
M/M 

EDIN 

pos  i  t  i  ve-not  i  £  i  ca t  i  on 
negat  i  ve-not  i  £  i cat  ion 
£orwar ded-not  i  £ i cat  ion 

0 
0 
0 

M/M 
M/M 
0/M 

FWD 

M/M 

CommonFields 
subject-edim 
edin-originator 
£irst-recipient 
not  i  £  i  cat  ion- 1  ime 
not  i  £  i  cat  ion-secur  i  ty-element s 

edin-initiator 

not  i  £  i  cat  ions-ext ens  ions 

M 
M 
0 
M 
0 

M 
0 

M/M 
M/M 
M/M 
M/M 
0/0 

M/M 
0/M 

SEC-A 
SEC-B 
SEC-C 

M/M 
M/M 
M/M 

See  Note  8 
See  Note  8 
See  Note  8 

See  Note  3 

Secur  i  tyElementFi  eld 
original-content 

original-content-integrity- 
check 

edi -application-security- 
elements 
secu  r  i  t  y-ex  t  ens  i  ons 

0 
0 

0 
0 

0/0 
0/0 

0/0 
0/M 

SEC-A 
SEC-B 
SEC-A 
SEC-B 

SEC-C 

M/M 
M/M 
M/M 
M/M 

M/M 

See  Note  6 
See  Note  6 

See  Note  3 
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Table  46  -  Classification  of  the  Pedl  protocol  elements  (continued) 


EDI  Messaging  Service  Protocol  (Pedi) 


Part  5  of  6 


Protocol  Element 


Support  by  EDI 
UA 
0/R 


FGs 


0/R 


Coaments/References 


PositiveNotificationFields 
pn-common- fields 
pn-supplenent  a  r y- i  nf orma t  i  on 
pn-extensions 

Nega t  i  veNot  i  f  i  ca t  i  onF  i  e Ids 
nn-coamon- fields 
nn-reason-code 

nn-supplementary-information 
nn-ex t  ens  i  ons 

NNReasonCodeF i e 1 d 
nn-ua-ms-reason-code 
nn-user-reason-code 
nn-pdau-reason-code 

NNUAMSReasonCodeF  i  e 1 d 
nn-ua-ms-bas  i  c-code 
nn-ua-ms -d  i  agnos  t  i  c 

NNUserReasonCodeField 
nn-user-basi c-code 
nn-user -diagnostic 

NNPDAUReasonCodeF i e 1 d 
nn-pdau-bas  i  c-code 
nn-pdau-d  i  agnos  tic 

ForwardNotif icationFields 
f n-common- f i e 1 ds 
forwarded-to 
fn-reason-code 

fn-supplementary-information 
fn-ext ens ions 

FNReasonCodeFi  eld 
fn-ua-ms-reason-code 
fn-user-reason-code 
f n-pdau- r ea s on-code 

FNUAMSReasonCodeField 
fn-ua-ms-basi c-code 
f n-ua-ms -d  i  agnos  tic 
f n-secur  i  ty-check 


M/M 
0/M 
0/M 


M/M 
M/M 
M/M 
0/M 


M/M 
M/M 
0/M 


M/M 
M/M 


M/M 
M/M 


M/M 
M/M 


M/M 
M/M 
M/M 
0/M 
0/M 


0/M 
0/M 
0/M 


M/M 
M/M 
0/0 


See  Note  3 


See  Note  3 


FWD 


M/M 


See  Note  3 


See  Note  7 
See  Note  7 


SEC-A 
SEC-B 


M/M 
M/M 
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Table  46  -  Classification  of  tlie  Pedi  protocol  elements  (conduded) 


EDI  Messaging  Service  Protocol  (Pedi) 

Part  6  of  6 

Support  by  EDI 

Protocol  Element 

S 

0/R 

FGs 

0/R 

Comments/References 

FNUs  e  r ReasonCodeF  i  e 1 d 
£n-user-basic-code 
f n-user -d  i  agnos  tic 

FNPDAUReasonCodeField 
£n-pdau-bas  i c-code 
£n-pdau-d  i  agnos  tic 

M 
0 

M 

0 

Notes  1 

1  M  on  origination  if  the  implementation  supports  forwarding  of  a  multi 
part  EDIM  without  accepting  responsibility. 

2  Mamdatory  (on  origination)  v^en  an  implementation  supports  the 
removal  of  body  parts. 

3  Critical  extensions  must  be  supported  in  order  to  accept 
respons  ibi 1 i  ty . 

4  Use  of  supplementary  information  fields  requires  bilateral  agreement. 

5  Mandatory  on  origination  if  removal  of  body  parts  is  supported. 

6  One  of  these  two  elements  must  be  supported  on  origination  \dien  using 
the  SEC-A  or  SEC-B  EDI  security  class. 

7  One  of  these  two  elements  must  be  supported  on  origination. 

8  M  on  origination  if  EDI-notif ication-security  or  EDI-reception-security 
(of  the  EDINotif icationRequestsFields)  are  supported  on  reception. 

A.12    Message  store  EDIMS  attribute  support 


A.I  3    Classification  of  the  P3  protocol  elements  for  physical  delivery 

The  protocol  elements  used  in  Table  48  should  be  viewed  as  a  delta  to  the  kernel  as  classified  in  Table  34. 
Thus,  Table  48  shows  the  additional  supported  required  in  P3  to  conform  to  the  Physical  Delivery  functional 
group. 
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Tabto  48  -  Classification  of  the  P3  protocol  elemsnts  for  physical  dslh/sry 


Mrs  Access  Protocol  (P3)  for  Physical  Delivery 


Part    1  of  1 


Static  Support  by: 


Protocol  Element 


UA 
0/R 


MS 
0/R 


MTA 

0/R 


Dyn 


Couaent s/Re£e r ences 


MessageSubai  ss  ionEnvelope 
extensions 
originator-return-address 
Pe r Rec i p i entMes s ageSubmi s s i on 
Fields 
extensions 
E^xysical-forwarding- 
prohibited 
cer  t  i  £  i  cat  i  on-pa th 

ORNue 
extens  ion-at t r  ibutes 
jrtiysical-delivery-country- 

nane 
postal-code 

unformatted-postal-code 


M/- 


M/. 

M/. 


M/- 
M/- 
M/- 


M/- 


M/- 
M/- 


M/- 
M/- 
M/- 


-/M 


-/M 
-/M 


-/M 
-/M 
-/M 
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Annex  B  (normative) 
Object  identifiers 

B.I      X.400  SIG  object  identifiers 

The  X.400  SIG  object  identifiers  ail  allocated  under  the  mhsig  node  in  the  OIW  object  Identifier  subtree,  as 
defined  in  part  6  of  the  Stable  Implementors  Agreements  document.  This  definition  is  duplicated  in  figure 

15. 


id-nhsig    OBJECT  IDENTIFIER 

{  iso  (1)    iderati£ied-organization  (3)    oiw  (14)    mhsig  (6)  } 


Figure  15  -  Definition  of  tlie  mhsig  object  identifier 


The  X.400  SIG  has  defined  several  categories  of  object  identifiers.  Their  definition  is  provided  in  figure  16. 


id-mhsig-content-types       OBJECT  IDENTIFIER 

(  id-mhsig    content -types  (0)  } 

id-mhsig-body-part-types    OBJECT  IDENTIFIER  ;:= 

{  id-mhsig    body-part-types  (1)  } 


Figure  16  -  Defintion  of  tlie  X.400  SIG  Object  identifier  Categories. 

B.2     Content  types 

There  are  presently  no  object  identifiers  for  content  types  allocated  by  the  X.400  SIG. 
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The  object  identifiers  for  the  external  body  part  types  allocated  by  the  X.400  SIG  are  defined  in  figure  17. 


id-privacy-enhanced-mail    OBJECT  IDENTIFIER 

{  id-ahsig-body-part-types    pern  (0)  } 


Figure  17  -  Definition  of  the  External  body  part  object  identifiers 


8.4     Security  classes 

The  ASN.1  expressed  in  figure  18  defines  the  security  Object  Identifiers  specified  by  these  Implementation 
Agreements.  These  are  the  same  as  defined  in  the  EWOS/ETSI  A/331 1  profile. 


id-mhs-security  OBJECT  IDENTIFIER  ::=  {  iso  (1) 

identified-orgsmization  (3)  ewos  (16)  eg  (2)  mhs  (4)  security  (4)  } 


id-policy- id 
id-category-id 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


—  Security  Policy  Object  Identifiers  — 


security- 
security- 
security- 
security- 
security- 
security- 


class-0 

class-Oa 

-class-1 

-class-la 

-class-2 

-class-2a 


OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 


IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 


—  Security  Category  Object  Identifiers  — 


private-id 
confidence- id 

comae  rc  i  a 1 - i  n-conf  i  dence- i  d 
management- i  n-conf  i  dence- i  d 
pe  r  sona 1 - i  n-con f  i  dence- i  d 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


id-mhs-security  1  } 
id-mhs-security  2  } 


id-policy-id  0  } 

id-policy-id  0  1 

id-policy-id  1  ) 

id-policy-id  1  1 

id-policy-id  2  ) 

id-policy-id  2  1 


id-category-id  0 
id-category-id  1 
id-category-id  2 
id-category-id  3 
id-category-id  4 


Figure  18  -  Security  object  identifiers 
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Annex  C  (informative)  | 

Interpretation  of  elements  of  service  > 

The  objective  of  this  dause  is  to  provide  clarification,  wfiere  required,  on  the  functionality  of  Elements  of  ' 
Service  wfiere  the  MHS  standards  are  unclear  or  ambiguous.  It  is  not  the  intent  of  this  dause  to  define  how  I 
information  should  be  made  available  or  presented  to  an  MHS  user,  nor  is  it  intended  to  define  how  I 
indiv^ual  vendors  should  design  their  products.  i 

The  following  MHS  Elements  of  Service  require  further  text  to  be  added  to  their  definitions  to  represent  the  I 
proposed  impiementation  of  these  Elements  of  Service  for  conformance  to  this  Agreement.  Elements  of  ' 
Service  which  are  not  referenced  In  this  dause  are  as  defined  In  the  MHS  base  standards. 

Reply  Request  Indication:  The  reply-recipients  and  the  reply-time  may  be  specified  without  any  explicit  reply 
being  requested.  This  may  be  Interpreted  by  the  recipient  as  an  implicit  reply  request. 

I 

NOTE  -  For  an  auto-fbrwarded  message  an  explicit  or  implicit  reply  request  may  not  be  meaningful.  ( 

i 

Fon^arded  IP-message  Indication:  The  following  use  of  the  original  encoded  information  type  in  the  context 
of  forwarded  messages  is  darified: 

a)  The  encoded  information  types  of  the  message  being  forwarded  should  be  reflected  In  tfie  new 
original  encoded  Information  types  being  generated. 

b)  If  forwarding  a  privately  defined  body  part  (see  figure  10),  the  originator  of  the  fonwarding  ! 
message  shall  set  the  original  encoded  information  types  In  the  PI  envelope  to  Undefined  for  that 
body  part. 
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Annex  D  (informative)  

Recommended  practices 

This  clause  provides  guidelines  on  areas  not  addressed  by  the  base  standards.  These  guidelines  have  been 
I  produced  In  order  to  promote  awareness  of  interim  solution  to  problems  as  agree  by  members  of  the  OIW 
I  X.400  SIG.  However  implementors  of  these  recommended  practices  should  note  that  It  is  not  necessary  to 
foHow  the  recommended  practices  when  claiming  conformance  to  these  agreements. 

L  Implementors  should  also  note  that  future  standardization  by  CCITT  and  ISO/iEC  on  area  covered  by  this 
I  clause  may  result  In  different  solutions  to  those  proposed  in  this  clause. 


Hi  D.I     Printable  String 

There  are  existing  mail  systems  that  include  a  small  set  of  non-Printable  String  characters  in  their  identifiers. 

For  these  systems  to  communicate  with  MHS  systems,  either  for  pass-through  service  or  delivery  to  MHS 
j  users,  gateways  will  be  employed  to  encode  these  special  characters  into  a  sequence  of  Printable  String 
i^l  characters.  This  conversion  should  be  performed  by  the  gateway  according  to  a  comnK>n  scheme  and 
1 1  before  Insertion  In  Domain  Defined  Attributes,  which  are  intended  to  canv  electronic  maH  identifiers.  MHS 
'  UAs  may  also  perform  such  conversions. 

i 

I !  It  Is  recommended  that  the  following  symmetrical  encoding  and  decoding  algorithm  for  non-Printable  String 
1 1  characters  be  employed.  The  encoding  algorithm  maps  an  ASCII  representation  to  a  PrintableString 
|l  representation.  Any  non-printable  string  characters  not  specified  in  table  49  are  covered  by  the  category 
« "other." 


Table  49  -  Printable  String  to  ASCII  mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

§  (at  sign) 

(a) 

1  (excleuaation) 

(b) 

"  (quote  mark) 

(q) 

_  (underline) 

(u) 

(  (left  paren. ) 

(1) 

)  (right  paren.) 

(r) 

other 

(3DIGIT) 

Where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal  encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  PrintableString,  table  48  and  the  algorithm  in  figure  19  should  be 
used. 
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IF  current  character  is  in  the  encoding  set  THEN 

encode  the  character  according  to  table  48 
ELSE 

write  the  current  character; 
continue  reading; 


Figure  19  -  ASCII  to  PrintableString  algorithm 

To  decode  a  PrintableString  representation  to  an  ASCII  representation,  table  48  and  the  aigoritiim  in  figure 
20  should  be  used. 


IF  current  character  is  not  "("  THEN 

write  character 
ELSE 

{ 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  table  48  THEN 

decode  per  table  48 
ELSE 

write  current  character; 
continue  reading; 


D.2 


Figure  20  -  PrintableString  to  ASCII  algorithm 

Rendition  of  lASText 


The  characters  that  may  be  used  in  an  lASString  are  tiie  graplilc  characters  (Including  Space),  control 
characters  and  Delete  of  the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a  guaranteed  rendition  are  those  related  with  positions  2/0 
to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code  table.  ^ 

The  otiier  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a  subset  consisting  of  the  format 
effectors  0/10  {\JF),  0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the  following  combinations 
as  defined  In  table  50. 

Table  50  -  Interpretation  of  format  effector  combinations 


Combination 

Interpretation 

CR  LF 
CR  FF 
LF   ..  LF 

to  start  a  new  line 
to  start  a  new  page  (and  line) 
to  show  empty  lines  (always  after  one  of  the 
preceding  combinations). 

The  other  control  characters  or  the  above  control  characters  in  different  combinations  may  be  used  but  have 
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no  guaranteed  effect. 

The  character  Delete  nnay  cx;cur  but  has  no  guaranteed  effect.  The  lASString  in  a  P2  lASText  BodyPart 
represents  a  series  of  lines  which  may  be  divided  into  pages.  Each  line  should  contain  from  o  to  80  graphic 
characters  for  guaranteed  rendition.  Longer  lines  may  be  arbitrarily  t>roken  for  rendition. 

NOTE  -  X.408  states  that  for  conversion  from  lASText  to  Teletex.  the  maximum  line  length  Is  77  characters. 


D.3     EDI  use  of  MHS 

This  section  outlines  a  recommended  method  for  Interworklng  between  a  P(edi)  UA  with  a  UA  implementing 
the  Recommended  Practice  (EDI  Use  of  X.400)  In  parts  7  and  8  of  the  OiW  Stable  Implementation 
Agreements.  That  Recommended  Practice  is  commonly  referred  to  as  the  "PO"  approach  to  EDi  use  of 
the  X.400  MTS. 

This  section  does  not  define  where  the  conversion  between  the  two  content  types  occurs,  it  is  possible  for 
the  conversion  to  be  performed  by  the  PO  UA,  the  P(edi)  UA,  or  a  gateway.  The  Recommended  Practice 
outlined  in  this  section  only  attempts  to  document  the  rules  that  should  be  followed  to  ensure  a  conversion 
which  retains  the  maximum  amount  of  information. 


D.3.0.1        PO  to  P(edl)  conversion 

The  converting  entity  may  assume  that  the  PO  content  contains  only  one  EDI  interchange.  This  interchange 
will  become  the  first  and  only  body  part  of  the  EDIM. 

The  content  type  field  of  the  message  will  have  the  value  "undefined"  before  the  conversion  and  wHI  have 
the  integer  value  "35"  or  the  object  identifier  value  for  P(edi)  which  is  specified  in  X.435  after  conversion. 
The  EDIM  Heading  fields  can  be  fonned  using  the  following  rules: 

EDIMIdentifier:  Originator  ORName  concatenated  with  the  UTCTIme  at  which  the  conversion  from  PO  to 
P(edi)  was  performed. 

Originator:  Originator  ORName. 

Recipients:  Recipients  from  the  PI  envelope.  EDI  Notification  Requests  are  not  specified  as  none  are 
I  requested  when  using  the  PO  approach. 

I  EDIBodyPartType:  This  element  may  have  one  of  deveral  values  depending  on  the  encoded  infonnation  type 
I  (EiT)  value  of  the  PO  message  or  the  ability  of  the  converting  entity  to  determine  which  EDi  syntax  is  present 
I  in  the  content: 

a)  X.435-deflned  value  for  ANSI  X12/EBCDIC  if  the  EIT  field  of  the  PI  envelope  has  the  value 
I  "undefined". 

I  b)  X.435-defined  value  for  ANSI  X12/IS0  646  If  the  EiT  field  of  the  PI  envelope  has  the  value 

"lASStrlng". 
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c)  Any  other  valid  value  If  the  entity  perfonning  the  conversion  can  determine  which  EDI  syntax  is 
contained  in  the  content  and  which  character  encoding  is  used  for  the  EDI  syntax. 

Other  heading  fields  will  only  be  set  if  the  entity  performing  the  conversion  is  capable  of  parsing  the  EDI 
Interchange  and  discovering  the  correct  values  ol  EDI  Heading  fields. 

As  the  PO  message  will  not  contain  requests  for  EDI  Nc^ifications,  an  EDI  UA  will  never  create  an  EDIN  when 
it  receives  an  EDIM  converted  from  PO  . 

i 

D.3.0.2        P(edi)  to  PO  conversion  | 

When  converting  a  P(edi)  content  to  a  PO  content,  the  foilowing  rules  apply: 

The  first  body  part  of  the  EDIM  will  be  copied  to  the  content.  All  other  body  parts  of  the  EDIM  will  be 
discarded. 

The  P1  envelope  fields  shall  have  the  following  values:  ; 

\ 

Content  Type:  Value  for  "undefined".  | 

Originator:  Originator  ORName.  j 

Recipients:  Recipients  from  the  EDIM  Heading.  An  NN  EDIN  with  NN  Reason  Code  set  to  the  value  ] 
"unspecified"  is  created  for  each  Recipient  for  whom  a  Notification  Request  was  specified.  The  EDIN 
Originator  is  set  to  the  Recipient  ORName.  It  is  recommended  that  the  supplementary  information  field  of  < 
the  NN  be  used  to  provide  additional  information  on  the  disposition  of  the  EDIM. 

Encoded  Information  Types  (EITs):  This  element  may  have  one  of  several  values  depending  on  the  value 
of  the  EDI  Body  Part  Type: 

a)  The  EIT  is  set  to  "undefined"  if  the  EDI  Body  Part  Type  is  encoded  with  the  EBCDIC  character 
set. 

b)  The  EIT  is  set  to  "lASString"  if  the  EDI  Body  Part  Type  is  encoded  using  the  ISO  646  (ASQI) 
character  set. 

c)  A  value  is  not  present  for  the  EIT  if  EDI  Body  Part  Type  does  not  contain  one  of  the  above 
mentioned  values. 


D.3.1       P2  recommended  practice 

As  there  are  a  substantial  number  of  users  in  the  NIST  OIW  community  that  implemented  the  CEC  TEOIS  j 
"Pa"  approach  to  EDI  use  of  the  X.400  MTS,  this  section  will  also  include  text  that  describes  intenworking  1 
between  a  P(edi)  UA  and  a  P2  UA.  This  text  is  not  maintained  by  the  EDI  Working  Group  of  the  NIST  OIW  J 
X.400  SIG  but  is  included  for  the  convenience  of  our  user  community.  Users  intending  to  intenA^ork  between 
P2  and  P(edi)  User  Agents  should  consult  the  cun-ent  version  of  the  EWOS/ETSI  document  "A/3331  - 
Functional  Profile  of  an  Electronic  Data  Interchange  User  Agent."  This  will  ensure  that  the  most  up  to  date 
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D.3.1.1        Conversion  from  IPMS  to  EDIMS  (P2  to  P(edl)) 

It  is  assumed  that  there  is  one  and  only  one  body  part  in  the  IPM  Message,  and  that  this  body  part  contains 
an  EDI  interchange. 

The  IPM  becomes  the  first,  and  only,  body  part  of  the  EDIM. 
The  EDIM  Heading  fields  are  set  as  follows: 

EDIMIdentifier:  Originator  ORName  concatenated  with  the  LocaliPMIdentifler  portion  of  the  IPM  Identifier. 
Originator:  Originator  ORName. 

Recipients:  Recipient  ORNames  from  the  IPM  Heading.  The  edi-notification-requests-field  is  not  coded. 

EDIBodyPartType:  The  value  is  a  local  implementation  issue.  If  the  entity  performing  the  conversion  can 
identify  the  EDI  syntax  of  the  EDI  Interchange  then  it  can  specify  an  appropriate  value.  Oth&rwise,  the  entity 
must  be  assuming  a  specific  encoding  and  will  specify  the  value  for  the  syntax  it  is  assuming. 

Other  heading  fields  may  be  set  if  the  entity  performing  the  conversion  is  capable  of  parsing  the  EDI 
Interchange  and  discovering  the  correct  values  of  the  EDIM  Heading  fields. 

;  Since  there  are  not  notification  requests,  the  EDI  UA  will  never  create  an  EDIN  when  it  receives  a  converted 
EDIM  and  therefore  the  action  for  handling  EDINs  in  the  reverse  direction  does  not  need  to  be  considered. 


D.3.1.2        Conversion  from  EDIMS  to  IPMS  (P(edl)  to  P2) 

•  NOTE  -  The  verification  of  authority  to  perform  a  particular  conversion  is  outside  the  scope  of  this  annex,  tt 

is  assumed  that  such  conversion  will  be  done  with  the  full  knov^edge  of  the  originating  and  recipient  parties. 

The  EDIBodyPart  of  the  EDIM  will  be  copied  to  the  IPM  body  as  an  lASTextBodyPart.  All  other  body  parts 
of  the  EDIM  will  be  discarded. 

The  IPM  Heading  fields  are  set  as  follows: 

IPM  Identifier:  EDIMIdentifier. 

\Originator:  Originator  ORName. 

\Recipients:  Recipients  from  the  EDIM  Heading.  All  recipients  become  IPM  Primary  Recipients.  An  NN  EDIN 
Jwith  NN  Reason  Code  set  to  the  value  "unspecified"  is  created  for  each  Recipient  for  whom  a  Notification 
^Request  was  specified.  The  EDIN  Originator  is  set  to  the  Recipient  ORName.  The  EDIN  Originator  is  set 
Dito  the  Recipient  ORName.  IPM  Notifications  shall  not  be  requested. 

^Subject:  Not  present  or  set  to  a  single  blank  character. 
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If  EDINs  have  been  requested  the  originator  wll  always  receive  an  NN.  Since  no  IPM  notifications  are 
requested,  the  IPM  UA  will  never  create  an  IPM  notification  when  it  receives  an  IPM  converted  from  an  EDIM 
and  therefore  handling  of  notifications  in  the  reverse  direction  does  not  need  to  be  considered  and  is  not 
an  option  for  generating  EDINs. 


D.4     ODA  transfer 

To  ease  interworking  with  1984  implennentations  wlien  transferring  Office  Docunwnt  Architecture  (ODA) 
documents,  the  foilowing  are  recommerKled  for  1988  implementations: 

a)  Originatton  UA  implementing  1988  implementation  Agreements.  Tlie  1988  will  generate  the  ODA 
according  to  CCITT  Recommendation  T.41 1  Annex  E  for  the  destination  UA(s)  Implementing  1988 
Implenoentation  Agreements.  If  the  destination  UA  supports  1984  implementation  Agreements,  the 
approach  as  descrik>ed  in  section  7.12.8  is  recommended. 

b)  Recipient  UA  implementing  1988  Implementation  Agreements.  The  recipient  system  will  be  able 
to  handle  the  ODA  bodypart  in  P2  (1984)  as  defined  in  part  7,  B.8.1  for  interworking  with  1984 
implementation,  and  will  also  be  able  to  handle  the  ODA  bodypart  as  defined  in  the  appropriate 
base  standards. 

c)  MTA  downgrading  rules.  When  transferring  an  P22  with  ODA  body  part  in  P22  as  described  in 
T.41 1  to  an  1984  MTA,  the  EITs  kJentified  by  ODA  Object  identifiers  are  mapped  to  bits  0  and  10 
of  the  built-in  EITs. 

If  the  UA  does  ncrt  register  to  support  P22  or  ODA  bodypart,  a  Non-Delivery-Report  will  t>e  generated  as 
required. 


D.5     Use  of  externally  defined  body  part 


D.5.1  General 

An  Externally  Defined  body  part  represents  an  information  object  whose  semantics  and  abstract  syntax  are 
denoted  by  an  Object  Identifier  whtoh  the  body  part  carries.  This  txxJy  part  type  enables  the  exchantge  of 
informatton  objects  of  ail  kinds,  each  unambiguously  and  uniquely  kJentified. 

The  Externally  Defined  Body  Part  definition  is  reproduced  in  figure  22. 
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External lyDef i nedBodyPar t 
parameters 
data 

ExternallyDefinedParameters 
External lyDefinedData 

EXTERNAL 

di  rect-reference 
indirect-reference 
data-value-descr  iptor 
encoding 

s  ingle-ASNl-type 

octet-aligned 

arbitrary 


SEQUENCE  { 

[0]  ExternallyDefinedParameters 
ExternallyDef inedOata  } 


OPTIONAL, 


EXTERNAL 
EXTERNAL 

[UNIVERSAL  8]     IMPLICIT  SEQUENCE  { 
OBJECT  IDENTIFIER  OPTIONAL, 
INTEGER  OPTIONAL, 
ObjectDescriptor  OPTIONAL, 
CHOICE  { 
[0]  ANY, 

[1]     IMPLICIT  OCTET  STRING. 
[2]     IMPLICIT  BIT  STRING     }  } 


Note  -    In  the  case  of  transfer  of  EXTERNAL  in  P2  BodyPart,  the 
direct-reference  component  is  mandatory  and  the  indirect-reference  and 
data-value-descriptor  components  must  be  absent. 


Figure  22  -  Externally  Defined  body  part  definition 

On  the  basis  of  the  Externally  Defined  body  part  type,  all  body  part  types  are  divided  into  two  important 
classes  as  follows: 

a)  basic:  Said  of  any  body  part  type  except  Externally  Defined.  All  basic  body  part  types  are 
denoted  by  an  integer  (an  ASN.1  context-specific  tag)  and  are  defined  in  section  7.3  of  X.420. 

b)  extended:  Said  of  the  Externally  Defined  body  part  type  restricted  to  any  one  value  of  the 
Direct-reference  component  of  the  Data  component  of  such  a  body  part.  Denoted  by  an  Object 
Identifier. 


Annex  B  of  Recommendation  X.420  defines  some  (but  not  necessarily  ail)  extended  body  part  types. 


D.5.2      Use  Of  equivalents  of  basic  body  part  types 

For  each  basic  body  part  types,  section  B.1  of  Recommendation  X.420  defines  an  equivalent  extended  body 
part  type.  In  order  to  facilitate  interworking  with  1984  systems,  use  of  these  extended  body  part  types  is 
not  recommended;  the  basic  body  part  types  should  b>e  used  instead. 

Editor's  Note:  The  requirements  of  this  clause  may  change  when  intenworking  with  1984  systems  is  no 
longer  critical. 

D.5.3       Use  of  General  Text  body  part  type 

Unless  othenvise  specified  in  these  agreements  (e.g..  lASText.  6937Text,  Teletex)  the  General  Text  body  part 
as  defined  in  ISO  10021-7  Annex  8.2  is  the  preferred  means  of  supporting  unstructured  text  body  parts. 
The  character  set  registration  referred  to  in  that  annex  is  provided  by  ECMA. 
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D.5.4      Use  of  File  Transfer  body  part  type 

The  Fie  Transfer  body  part  type  is  the  recommended  mechanism  for  the  exchange  of  complex  computer 
data  via  intra-  and  inter-company  X.400  messages,  it  enables  automatic  type  recognition  for  tlie  fHe  being 
sent  and.  possibly,  automatic  invocation  of  the  appropriate  application  necessary  to  process  the  data. 


In  order  to  optimize  the  machine-processing  of  Information  encoded  in  the  Parameters  and  to  enable 
registration.  It  Is  recommended  that,  if  present.  General  Identifiers  should  be  encoded  as  Object  Identifiers. 


It  Is  recommended  that  the  Contents  Type  parameter  be  encoded  as  document  type.  The  encoding  as 
constraint-set-and-abstract-syntax  has  been  provided  only  for  bacl<ward  compatibility  with  FT AM  and  its  use 
is  discouraged. 


D.5.4.3       Encoding  of  application  specific  information 

The  type  of  a  file  can  be  considered  from  several  perspectives: 

a)  As  a  specific  data  structure  consisting  of  a  sequence  of  presentation  data  values  -  the  position 
taken  by  the  FTAM  standard; 

b)  As  the  output  of  a  certain  application  -  the  position  tal<en  by  e-mail  users  requiring  the 
Interchange  of  office  documents. 


The  feet  that  registered  OSI  document  types  have  to  be  recognized  by  FTAM  implementations  and  be 
described  according  to  the  requirements  of  ISO/IEC  9834-2  "Registration  procedures  for  OSI  document 
types"  makes  use  of  the  Contents  Type  parameter  inappropriate  for  expressing  point  of  view  (b). 

ConskJering  that  the  environment  parameter  "application-reference"  could  describe  not  only  the  applteation 
tfiat  generated  a  document  ixit,  more  generally,  the  applbation-level  format  of  the  document,  it  is 
recommerxJed  tfiat  the  values  given  to  the  "applteation-reference"  parameter  component  be  Object  Identifiers 
associated  with  such  a  format. 

Example:  If  an  Object  Identifier  has  been  associated  with  a  certain  word-processing  file  format  then  this 
Object  Identifier  sfK>uld  be  used  as  the  value  of  "application-reference"  when  a  file  of  that  format  is  carried 
by  a  Fie  Transfer  body  part,  whHe  the  Content  Type  parameter  should  have  as  its  value  the  Object  Identifier 
associated  with  the  "unstrucutred-binary"  document  type. 


D.S.4.1 


Encoding  of  General  Identifier 


D.5.4.2 


Encoding  of  Contents  Type 
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It  Is  recommended  to  use  only  the  kJ-eit-file-transfer  Object  Identifier  in  association  with  the  File  Transfer 
txxiy  part. 

The  use  of  EITs  describing  other  parameters  of  the  File  Transfer  body  part  such  as  contents  types, 
application  references,  etc.  would  force  all  potential  recipients  to  register  a  possibrfy  large  numt>er  of  EITs 
in  order  to  avoid  non-delivery  of  messages. 


D.5.5       Use  of  other  extended  body  part  types 

The  following  are  guidelines  regarding  the  use  of  Externally  Defined  body  part  types  not  defined  in  the  X.400 
or  other  standards: 

a)  Use  of  Parameters  component:  In  simple  cases,  to  ease  the  Integration  of  applications  to  X.400 
systems,  the  Parameters  component  need  not  be  used. 

b)  Use  of  Data  component:  For  each  different  format  of  data,  different  Object  ider^tifiers  for  the  Data 
component  are  recommended.  If  an  application  chooses  to  use  ASN.1  to  format  the  data  to  achieve 
a  single  representation  across  platforms,  the  singie-ASN1-type  encoding  choice  should  be  used. 
OtheoA/ise: 

1)  The  octet-  (i.e.,  byte)  aligned  choice  is  used  if  the  data  format  is  octet-aligned;  or, 

2)  The  arbitrary  choice  is  used  if  the  data  is  bit-aligned. 

c)  Assignment  of  Object  Identifiers:  Object  identifiers  need  to  be  assigned  for  the  EXTERNALS,  and 
these  identifiers  for  the  Parameters  and  Data  components  should  be  different.  The  Object  identifier 
for  an  EXTERNAL  also  indicates  the  syntax  of  the  data  encoding,  i.e.,  whether  singie-ASN1-type  or 
octet-aligned  or  bit-aligned  is  being  used. 

NOTE  -  Use  of  proprietary  Externally  Defined  body  part  types  is  recommended  only  if  the  extended  Ixxly  part 
types  already  defined  in  the  standards  do  not  provide  the  apporpriate  functionality. 

In  order  to  communicate  with  1984  systems,  the  use  of  the  Bilaterally  Defined  body  part  is  recommended. 


D.5.6      Obtaining  object  identifiers 

There  are  many  ways  to  obtain  object  Identifiers.  One  such  way  is  described  as  follows: 

a)  The  application  provider  obtains  a  unique  Numeric  Name  form  for  their  organization  from  ANSI, 
as  described  in  ANSI  ISSB  840  and  ISSB  843,  and  appends  this  number  form  to  {iso  (1)  member- 
body  (2)  US  (840)}  to  form  an  object  identifier  denoting  their  organization. 

b)  The  application  provider  (organization)  allocates  a  series  of  numbers  to  identify  the  application 
data  format;  these  numbers  are  appended  to  the  object  identifier  constructed  in  step  (i)  to  fonn  an 
object  identifier  that  Is  globally  unique.  It  is  recommended  that  the  application  provider 
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(organization)  use  a  hierarchical  structure  for  identifying  their  data  types  to  ease  the  administration 
of  the  identifiers. 

For  example,  company  PCSoftware  Inc.  obtains  the  organization  number  "999"  from  ANSI.  The  PCSoftware 
Spreadsheet  file  for  MS-DOS  might  be  assigned  the  following  object  identifier. 

NOTE  -  ASN.1  notation  is  used.  The  numbers  in  parentheses  form  the  identifier,  the  associated  words  j 
describe  the  numi^er.  ) 

{  ISO  (1)  member-body  (2)  US  (840)  PCSoftware  Inc.  (999)  MS-DOS-Application  (1)  Spreadsheet 
(3)  Data  (1)  } 

D.6     Privacy  Enchanced  Mail  body  part 

This  clause  descrit>es  a  mechanism  to  convey  an  Intemet  Privacy  Enhanced  Mail  (PEM)  message  across 
an  X.400  MHS.  PEM  is  described  in  Intemet  RFCs  1113, 1114,  and  1115  and  their  successors. 

The  general  Intemet  mail  message  format  is  descrit)ed  in  RFC  822.  Mapping  of  RFC  822  messages  to  and 
from  X.400  Inter  Personal  Messages  is  described  in  RFC  987  for  1984  X.400  and  in  RFC  1 148  for  1988  X.400. 

The  PEM  message  is  conveyed  as  a  P2(2)  body  part.  All  of  the  RFC  822  header  information  is  conveyed  f 
in  the  PI  envelope  and  P2  header  per  RFC  987  and  RFC  1 148.  The  PEM  message  (encapsulated  security  ^ 
header  and,  possibly  encrypted,  message  text  as  described  in  RFC  1 1 13)  is  conveyed  in  a  single  body  part. 
On  the  X.400  side,  this  body  part  may  be  manipulated  lil<e  any  other  txxiy  part;  e.g.,  It  may  t>e  Included  in 
a  multi-part  body. 

For  1988  (P22),  the  PEM  body  part  is  externally  defined  and  does  not  require  parameters.  This  definition  is 
provided  in  figure  23. 


pr  i  vacy-enhanced-ma  i 1  EXTENDED-BODY-PART-TYPE 

DATA    OCTET  STRING 
::=  id-privacy-enhemced-mail 

—  The  object  identifier  is  defined  in  annex  B. 


Figure  23  -  Definition  of  the  Privacy  Enhanced  Mali  body  part  type 

For  intenwortdng  with  1984  (P2)  systems,  a  USA  body  part  (integer)  will  be  allocated  by  NIST  as  described 
in  figure  10. 
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r  D.7     Selection  of  OR  name  attributes 

I  To  support  the  transition  to  addresses  witli  Teletex  components,  it  is  recommended  t^^at  a  printable  string 

>i  alternative  address  be  established  for  each  address  containing  Teletex  strings. 


'I  D.8     Use  of  the  Teletex  body  part 

)  The  Teletex  body  part  should  be  used  purely  for  stmctured  teletex  documents,  as  described  in  F.200  and 
T.60,  obeying  page  rules,  etc.  It  should  not  be  used  to  transfer  T.61  characters,  in  a  general  sense,  across 
the  MTS.  If  only  IA5  characters  are  being  used,  the  lASText  body  part  should  be  used,  especially  when 
interworking  with  1984  UAs  is  relevant.  Othenvise,  the  GeneralText  body  part  should  be  used  to  transfer 
unstructured  character  data. 


D.9     Provision  of  security  class  SOA  using  asymmetric  algorithms 

This  clause  describes  one  method  of  providing  the  security  services  of  class  SOA  when  using  asymmetric 
(public  key)  cryptographic  algorithms.  It  is  recommended  that  this  method  be  used  unless  the  security 
jl  requirements  or  policy  specifies  otherwise.  Asymmetric  cryptographic  algorithms  such  as  RSA  are  used  to 
provkje  digital  signatures  in  support  of  the  content  integrity  and  (end-to-end)  message  origin  authentication 
t  servk^,  as  well  as  proof  of  delivery.  Since  asymmetric  algorithms  are  used,  the  non  repudiation  of  origin 
I  and  non  repudiation  of  delivery  services  of  security  class  S2  are  also  provided.  Content  confidentiality  is 
provkJed  using  a  combination  of  symmetric  and  asymmetric  encryption.  The  following  paragraphs  discuss 
the  protocol  elements  used  to  provide  these  services,  as  well  as  certificate  management  and  other  issues. 


D.9.1       Protocol  elements 

'  The  following  protocol  elements  are  provided  by  the  originating  UA  in  the  submission  envelope  in  support 
of  the  SOA  security  services. 

11 

I  j  Content:  If  the  content  confidentiality  services  is  required,  the  message  content  is  encrypted  under  the 
"I  content  confidentiality  key. 

i 

j  Content  Integrity  Check:  This  per-recipient  security  element  is  a  signature  over  the  message  content,  and 
provkJes  the  content  integrity,  message  origin  authentication,  and  non  repudiation  of  origin  services  if 
content  confidentiality  i§  jnQl  required.  (If  the  message  is  encrypted,  the  content  integrity  check  is  included 

g  in  the  message  token.) 

NOTE  -  The  message  origin  authentication  check  provides  a  single  signature,  rather  than  a  signature  per 
recipient,  thus  reducing  total  message  size  In  the  case  where  multiple  recipients  are  present.  However,  support 
for  this  protocol  element  Is  optional  for  security  class  SO.  In  addition.  It  Is  computed  over  the  message  content 
as  sent  (i.e.,  the  encrypted  content  if  content  confidentiality  Is  used).  If  the  content  Is  encrypted,  this  protocol 
element  does  not  truly  provide  non  repudiation  of  the  unencrypted  content.  In  this  case,  smaller  message  size 
was  traded  off  for  the  additional  service  of  non  repudiation. 

Proof  Of  Delivery  Request:  This  per-recipient  security  element  is  used  to  request  the  recipient  to  generate 
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a  proof  of  delivery,  in  the  case  where  content  confidentiality  is  not  used.  (Where  content  confidentiality  is 
used,  the  proof  of  delivery  request  is  included  in  the  message  token,  as  shown  l^elow.) 

Originator  Certificate:  This  security  element  is  a  set  of  one  or  more  certificates  which  the  recipient  may  use  » 
to  ot}tain  the  originator's  public  l<ey.  For  example,  It  might  contain  the  chain  of  certificates  from  the  ] 
originator,  through  the  certification  hierarchy  to  a  top-level  certification  authority. 

Message  Token:  The  asymmetric  message  token  conveys  security  information  from  an  originator  to  a  single  ! 
recipient.  It  is  a  signed  structure,  some  of  whose  fields  may  be  encrypted.  The  message  token  is  used  only  i 
when  content  confidentiality  is  desired,  and  supports  the  content  integrity,  message  origin  authentteation,  i 
content  confkJentiality,  and  non  repudiation  of  origin  services.  The  following  fields  are  required,  and  all  other  ij 
fields  are  optional:  i 

-  Signature  Algorittim  Identifier:  The  algorithm  kJentifier  of  the  asymmetric  algorithm  used  to  sign  I 
the  token.  ^ 

-  Recipient  Name:  The  OR  Address  and/or  Directory  Name  of  the  recipient  with  whom  the  token  j 
Is  associated.  Since  the  encrypted  portion  of  the  token  is  encrypted  under  the  recipient's  public  ^ 
key,  it  is  recommended  that  the  directory  name  be  included,  since  the  recipient's  certificate  contains  i 
his/her  directory  name  rather  than  OR  Address. 

-  Time:  The  time  of  day  when  the  token  was  generated.  | 

-  Signed  Data:  The  following  fields  are  signed  but  not  encrypted:  l| 

i 

a)  Content  Confidentiality  Algorittim  Identifier:  The  algorithm  to  be  used  to  encrypt  the  message  g 
content. 

b)  Proof  of  Delivery  Request:  This  element  is  used  to  request  the  recipient  to  compute  a  proof  of  ^ 
delivery  over  the  received  message. 

-  Encrypted  Data:  These  fields  are  encrypted  under  the  recipient's  public  key:  1 

c)  Content  Confidentiality  Key:  The  symmetric  key  used  to  encrypt  the  message  content.  | 

d)  Content  Integrity  Ciieclc   A  signature  on  the  unencrypted  message  content.   If  content^ 
confkJentiality  jg  required,  this  element  provides  the  content  integrity,  message  origin  authentication,  i 
and  non  repudiation  of  origin  services.  This  signature  is  encrypted  in  order  to  protect  against  the  | 
"low  entropy"  attack  described  in  Internet  RFC  1113.  (In  RFC  1113,  the  signature  is  encrypted  under 
the  content  confidentiality  key.)  ; 

ii 
t 

NOTE  -  The  encrypted  portion  of  the  token  will  then  comprise  two  RSA  encryption  blocks.  , 

The  following  element  of  service  is  generated  by  the  recipient,  if  requested  by  the  originator.  j 

Proof  Of  Delivery:  This  security  element  provides  proof  and  non  repudiation  of  delivery.  It  is  a  digital 
signature  computed  over  the  received  (possit>ly  encrypted)  message  content  and  various  delivery  envelope 
fields,  as  defined  in  the  iDase  standard. 
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!'l 

I  D.9.2      Algorithm  selection 

s  This  clause  makes  no  recommendation  as  to  bash  algorithms,  asymmetric  encryption  algorithms,  or 
[)|  symmetric  encryption  algorithms.  The  implementor  must  select  appropriate  algorithms,  based  on  factors 
I  such  as  performance,  cost,  and  licensing  and  export  restrictions.  A  fairly  complete  list  of  algorithms  can 

be  found  In  clause  7  (Security  Algorithms)  of  Part  12  of  these  Agreements.  In  some  cases,  the  implementor 
I  must  also  specify  certain  algorithm-dependent  infonnation.  For  example,  when  using  the  symmetric 
i  algorithm  DES-CBC.  the  implementor  must  specify  the  padding  mechanism  used,  since  this  algorithm 
\  operates  on  8-byte  input  blocks.  Internet  RFC  1115  defines  such  padding  rules  for  DES  and  RSA  in  various 
|i  modes,  and  these  mechanisms  are  recommended  unless  security  requirements  dictate  othenArise.  PKCS 

#1  (see  Biblk>graphy.  Annex  F)  discusses  such  matters  in  more  detail. 


'  D.9.3      Certificate  management 

I  Management  of  public  key  certificates  is  beyond  the  scope  of  this  recommended  practice.  X.509  provides 
I  a  generic  authentication  framework  which  uses  the  Directory  to  store  certificates.  In  the  absence  of  a 
f  ubkjultous  Directory,  local  means  may  be  used  to  obtain  certificates.  For  example,  the  recipient  of  a 

message  might  choose  to  cache  those  certificates  received  in  the  OriginatorCertificate  protocol  element 

of  the  delivery  envelope. 

Each  community  of  interest  will  define  its  own  policy  regarding  certificate  management  and  the  associated 
j  I  trust  model.  An  example  of  a  centralized  trust  model  can  be  found  in  Internet  RFC  1114,  while  the  most 
[l  complete  example  of  a  decentralized  trust  model  can  be  found  in  the  paper  on  Digital's  Distributed  System 
f\  Security  Architecture  cited  in  the  Bibliography  (Annex  F). 


D.9.4      Other  Issues 


In  the  case  of  the  P2  content  type,  addressing  information  may  be  protected  by  replicating  the  P1/P3 
I  j  recipient  names  In  the  P2  heading  fields  (To:,  CC:,  and  BCC:).  The  X.400  security  services  discussed  above 
I  are  applied  to  the  entire  P2  IPM,  including  the  heading  and  all  body  parts.  Additional  protection  of  heading 

and  envelope  fields  may  be  provided  using  double  enveloping. 

I  When  using  X.400  (1988)  distribution  lists  (DLs),  one  might  choose  to  distribute  the  private  key  associated 
with  the  DL  to  all  members  of  the  DL  This  allows  an  originator  to  create  a  single  message  token  in  which 
the  content  confkJentiality  key  is  encrypted  under  the  DL's  public  key.  (This  requires  support  of  the  DL 

f  expanston  history  protocol  element  on  delivery,  so  that  the  recipient  may  select  the  proper  private  key  for 
decryptton.  Alternatively,  the  originating  UA  may  expand  the  DL  locally  and  generate  a  message  token  for 

j  each  member  [recursively]).  There  Is  no  architected  support  for  this  mechanism  in  the  base  standard,  nor 

|l  Is  there  architected  support  for  performance  of  this  function  by  an  MTA  when  expanding  a  DL 
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Annex  E  (informative)   

Secure  messaging  guidelines 

E.1  Introduction 

The  purpose  of  the  security  functional  group  is  to  define  an  approach  to  the  provision  of  secure  messaging 
with  Message  HarxJIIng  systems  within  the  general  framework  of  these  Implementation  Agreements. 

E.2     Message  handling  vulnerabilities 

The  message  handling  vulnerabilities  (threats)  which  can  t>e  protected  using  security  measures  are  defined 
In  Annex  D  (Security  Threats)  to  Recommendation  X.402  (1988): 

a)  Masquerading; 

b)  Message  sequencing; 

c)  Modification  of  Information; 

d)  Denial  of  service; 

e)  Repudiation; 

f)  Leakage  of  Information. 

Other  specKk:  threats  exist  if  there  is  a  failure  to  maintain  information  separation,  whteh  Includes: 

a)  Manipulation; 

b)  Misrouting. 

Some  of  these  threats  are  defined  in  ISO  standard  IS  7498.  OSI  Reference  Model.  Part  2:  Security 
Architecture.  The  ISO  standard  also  specifies  other  threats,  not  all  of  which  are  relevant  to  message  handling 
systems. 

Annex  D  to  CCITT  Recommendation  X.402  (1988)  also  indteates  which  MHS  security  services  may  provide 
protectbn  against  such  threats. 

Some  threats  to  message  handling  systems  cannot  be  easily  prevented,  merely  detected,  others  are  not 
appropriated  for  standardization. 
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E.3.1       Security  policy 

A  general  security  policy  can  be  defined  as  the  set  of  laws,  rules,  and  practices  that  regulate  how  an 
organization  manages,  protects,  and  distributes  sensitive  information.  Thus  a  security  policy  defines  an 
organizatton's  overall  approach  to  security  and  must  cover  ail  security  aspects. 

Security  within  an  organization  is  not  only  the  concern  of  message  handling  service  and  must  be  viewed 
in  a  more  global  and  general  sense.  The  wider  aspects  of  a  security  policy  would  therefore  Include 
personnel  security  (such  as  the  vesting  and  confidence  placed  in  staff),  end-user  access  control,  physical, 
procedural  and  documentation  security.  These  Implementation  Agreements  however  are  only  concemed  with 
Electronic  Information  Security  (EIS),  specifically  in  the  areas  of  communications  (COMSEC)  and  computer 
(COMPUSEC)  as  applicable  to  standardization  of  a  secure  message  handling  system  operating  in  a  store 
and  forward  environment. 


E.3.2      Security  classes 

In  the  X.400  (1988)  Recommendations,  some  threats  are  countered  by  EIS  measures,  these  measures  are 
realized  by  providing  security  services  and  implemented  using  security  elements. 

These  Implementation  Agreements  groups  together  security  features  of  a  message  handling  system  defined 
by  the  base  standards  into  separate  classes.  A  security  class  can  be  viewed  as  a  tool  which  can  be  used 
to  implement  a  security  policy,  and  is  not  a  security  policy  in  its  own  right  but  a  component  of  a  security 
policy. 

These  Implementation  Agreements  includes  a  set  of  security  classes;  each  class  stipulates  a  set  of 
mandatory  and  optional  security  services.  The  security  classes  are  incremental  subsets  of  the  security 
features  in  the  MHS  Base  Specifications: 

Security  Class  SO  only  requires  support  of  end-to-end  security  services  t)etween  UAs  (content 
Integrity,  message  origin  authentication,  proof  of  delivery),  and  hence  can  be  used  to  provide  some 
protection  even  in  the  case  of  transit  through  an  intermediary  MTS  which  may  not  b>e  trusted. 

Security  Class  S1  additionally  requires  support  and  use  of  secure  access  management  within  the 
MTS  so  as  to  allow  the  enforcement  of  a  label-based  security  policy  and  enable  trusted  interworl<ing 
between  security  domains. 

Security  Class  S2  additionally  requires  support  and  use  of  origin  authentication  checl<s  within  the 
MTS  to  verify  the  origin  of  messages,  probes,  and  reports,  thereby  mal<ing  it  possible  to  provide 
non-repudiation  within  the  MTS. 

Mandatory  security  services  within  a  security  class  can  be  selected  by  the  subscriber  or  user,  either  on  a 
per-message  basis,  or  for  an  agreed  contractual  period  of  time.  It  is  a  local  Issue  to  determine  when  a 
mandatory  security  service  is  offered  for  user  selection  or  when  It  Is  permanently  invoked.  Facilities  and 
mechanisms  to  support  the  mandatory  security  services  must  always  be  provided  within  the  security  dass, 
which  specifies  the  services  as  "mandatory." 
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E.3.3       Dynamic  behavior  requirements 

The  use  of  some  security  services  is  always  required  for  certain  security  classes.  Tliis  is  specified  in  these 
Implementation  Agreements  by  Imposing  additional  dynamic  requirements,  to  those  specified  in  the  base 
standards,  ensuring  that  the  corresponding  protocol  elements  are  always  present. 

Similarly,  use  of  some  security  services  are  prohibited  for  certain  security  classes.  This  is  specified  in  these 
Implementation  Agreements  by  imposing  additional  dynamic  requirements  to  those  specified  in  the  base 
standards,  ensuring  that  the  protocol  elements  are  never  present. 


E.3.4       Encryption  techniques 

The  secure  messaging  facilities  defined  in  the  base  standards  are  provided  using  three  basic  security 
techniques,  namely: 

a)  Symmetric  encryption; 

b)  Asymmetric  encryption; 

c)  Trusted  functionality  (i.e.,  COMPUSEC  measures). 

The  base  standards  permit  the  use  of  the  techniques  on  an  individual  basis  to  provided  security  services 
or  they  can  be  combined  in  support  of  a  security  policy.  These  Implementation  Agreements  combine  the 
techniques  in  order  to  provide  a  comprehensive  set  of  security  facilities,  which  are  intended  to  counter 
various  combinations  of  the  vulnerabilities  of  a  messaging  service.  In  some  cases  the  security  services 
defined  in  the  base  standards  can  only  be  implemented  using  one  of  the  techniques  above,  namely 
asymmetric  encryption.  However,  the  actual  technique  employed  shall  be  dependent  on  the  algorithms, 
which  shall  be  registered  by  a  security  authority  for  the  domain. 

It  is  the  intention  of  these  Implementation  Agreements  that  Implementations  will  not  be  restricted  to 
asymmetric  techniques.  All  the  mandatory  security  services  can  be  implemented  using  trusted  functionality 
in  combination  with  symmetric,  asymmetric,  or  both  encryption  techniques. 

Although  the  base  standards  defines  the  syntax  of  an  asymmetric  token,  these  Implementation  Agreements 
takes  into  account  the  ISO/CCITT  MHS  Implementors'  Guide,  which  permits  the  use  of  both  asymmetric 
and  symmetric  techniques  for  both  the  signed  and  encrypted  data. 

The  actual  technique  employed  depends  on  the  algorithm  used.  Algorithms  are  assumed  to  be  bilaterally 
agreed  or  registered  by  a  registration  authority.  However,  the  algorithm-identifier  must  be  unique  and 
unambiguously  define  the  algorithm. 

It  is  recommended  that  a  conforming  ASN.1  BIT  STRING  is  normally  used  to  contain  the  encrypted  data  (as 
generated  by  use  for  the  ENCRYPTED  macro),  thereby  ensuring  insertion  of  padding  zero  bits  which  may 
be  necessary  for  correct  operation  of  certain  algorithms.  Alternatively,  the  implementation  should  take  such 
action  explicitly. 

It  is  recommended  that,  in  the  absence  of  any  requirement  for  support  of  other  specific  algorithms, 
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implementations  shali  as  a  default  support  algorltfims  identified  In  CCITT  X.509  (ISO/IEC  9594-8).  It  Is  also 
strongly  recommended  that  implementations  are  capable  of  using  any  encryption  based  technique  on  a 
"plug-in"  or  modular  basis. 

In  the  case  of  verification  of  SIGNATURES  (e.g.,  proof  of  delivery,  MOAC.  POAC.  or  ROAC),  implementations 
should  assume  that  all  relevant  data  present  in  the  subject  message,  probe,  or  report  has  been  included  in 
the  signature. 


E.3.5       Implementation  considerations 


E.3.5.1        Peer  Entity  authentication 

Peer  entity  authentication  is  provided  using  the  strong  authentication  mechanisms  on  the  various  Bind 
operations,  using  either  asymmetric  or  symmetric  techniques.  The  key  management  information  necessary 
for  symmetric  peer  entity  authentication  is  outside  the  scope  of  these  Implementation  Agreements. 


E.3.5.2  Confidentiality 

Connection  confidentiality  is  provided  using  the  underlying  OSI  layers  and  is  outside  the  scope  of  these 
Implementation  Agreements.  Mechanisms  to  support  connection  confidentiality  are  subject  to  bilateral 
i  agreement  between  peers  (i.e.,  connection  confidentiality  may  even  be  achieved  by  trusting  the  connection 
to  the  peer  OSI  entity). 

tii  Content  Confidentiality  may  be  achieved  by  either  symmetric  or  asymmetric  encryption  techniques.  It  should 
V  be  noted  that  use  of  asymmetric  techniques  precludes  submission  of  messages  to  multiple  recipients. 

i 

E.3.5.3  Integrity 

||  Connection  Integrity  is  provided  using  the  underlying  OSI  layers  and  is  outside  the  scope  of  these 
I  Implementation  Agreements.  Mechanisms  to  support  Connection  Integrity  are  subject  to  bilateral  agreement 
between  peers.  It  should  be  noted  that  the  integrity  of  a  connection  can  be  increased  by  use  of  RTSE. 

Content  Integrity  is  achieved  by  computing  a  content  integrity  checic  as  a  function  of  the  entire  message 
content.  When  symmetric  techniques  are  used  to  compute  the  content  integrity  check  a  secret  key  is 
i  required.  This  content  integrity  key  may  be  confidentially  sent  to  the  message  recipient  using  the  message 
f  argument  confidentiality  security  element  in  the  message  token  (i.e.,  there  may  be  other  keys  or  parts  of  the 
ki  key  not  sent  by  the  originator  with  the  message,  but  the  key  management  of  such  external  keys  is  outskJe 
j  the  scope  of  these  Implementation  Agreements).  It  should  be  noted  that  placing  the  content  integrity  check 
III  in  the  encrypted  data  of  the  message  token  will  provide  additional  protection  against  masquerade  threats. 

NOTE  -  Content  Integrity  can  also  provide  integrity  of  receipt  and  non-receipt  notifications  (IPNs)  and  can 
assist  in  the  provision  of  "non-repudiation  of  receipt"  since  non-repudiation  of  delivery  may  be  insufficient  where 
delivery  is  to  a  Message  Store. 
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E.3.5.4 


Message  origin  authentication 


End-to-end  O  e-  UA  to  UA)  Message  Origin  Authentication  is  automatically  provided  by  content  Integrity. 
Security  classes  S2  and  S2a  provide  additional  protection  (l  e.,  of  the  integrity  of  the  label)  by  requiririg 
support  of  origin  authentication  checks  within  the  MTS. 


If  asymn>etric  techniques  are  used  for  content  integrity  it  can  also  provide  non-repudiation  of  origin  (UA  to 
UA)  depending  on  the  level  of  trust  placed  in  the  certificate.  If  symnietric  techniques  are  used,  content 
integrity  can  also  provide  non-repudiation  erf  origin,  but  only  by  using  a  trusted  notary  to  validate  the  content 
integrity  and  provide  trusted  key  management  faclities.  A  degree  of  non-repudk»tk>n  can  be  provkJed  by 
the  use  of  trusted  accountability  sendees. 

NOTE  -  tt  is  assumed  that  an  originating  UA  will  ensure  that  delivefy  notificatton  Is  requested  when  proof  of 
delivery  is  requested. 


E.3.5.6        Secure  access  management 

Secure  Access  Management  can  be  implemented  by  a  comblnatk>n  of  Multi-Level  Security  (MLS) 
fufx:tionality  by  assurance  of  the  various  MhHS  components  to  support  such  functk>nality.  MLS  functkinality 
is  supported  in  the  base  standards  by  the  use  of  security  labels,  security  context  and  the  security  token  and 
can  be  applied  in  a  hierarchical  and/or  role  manner  depending  on  the  polk;y  requirements  of  a  domain. 

Mi^  assurance  will  generally  also  require  other  (COMPUSEC)  measures  and  is  outsMe  the  scope  of  the 
base  standards  and  these  Implementation  Agreements.  Reference  shoukJ  be  made  to  the  appropriate 
security  authority  and  any  applicable  security  evaluatk>n  criteria  (e.g.,  U.  S.  DoD  Orange  Book,  UK  - 
Netherlands  -  Germany  -  France  draft  Evaluatbn  Criteria). 


E.3.5.7        Implications  for  the  use  of  distribution  lists 

An  MTA  performing  distribution  list  expansion  must  create  all  the  per-recipients  fiekJs  for  the  members  of 
the  distribution  list.  It  may  either  generate  a  new  token  for  each  DL  nnember  O  e.,  using  the  recipient  name 
of  that  DL  member)  or  alternatively  it  may  copy  the  same  token  Q.e.,  containing  the  recipient  name  of  the 
DL  Itself)  into  the  per-reclplent  fields  for  each  DL  member.  In  the  former  case,  the  content-integrity-check 
shoukj  not  be  changed  if  it  is  to  be  used  to  provkie  message  origin  authentk^tk>n.  Also  in  such  case,  the 
DL  expansk)n  point  must  have  at  least  the  same  security  dass  as  the  originator  and  must  have  trusted 
functkxtallty.  The  choice  of  which  approach  to  use  will  therefore  need  to  be  determined  in  accordance  with 
the  security  polk:y  which  may  prohibit  the  use    distribution  lists  altogether. 


E.3.5.8        Implications  on  redirection 

The  Security  Functional  Group  has  the  effect  of  either  requiring  trust  in  any  redirection  facilities  or  prohibiting 
the  use  of  redirectk>n.  If  the  Redirection  facility  Is  to  be  tmsted,  it  must  be  subject  to  the  security  poltey  and 
obey  the  security  labels  as  defined  in  the  base  standards.  It  is  recommended  that  the  token  is  not  altered 


E.3.5.5 


Non-Repudiation 
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on  redirection  O-e.,  It  wHi  contain  the  originaliy-specified  recipient  name). 


E.3.5.9       Implications  for  1984  interworking 

interworking  between  implenientations  confomiing  to  Security  FunctlonaJ  Groups  and  1964  systems  is  not 
supported.  The  Double  Enveloping  technique  can  be  used  to  traverse  an  1984  system. 


E.3.5.10      Implications  for  use  of  Directory 

The  X.400  security  services  use  of  the  directory  service  does  not  require  a  trusted  directory  t)ecause  the 
information  that  is  retrieved  Is  certified  and  can  be  validated  indeperxlently  of  the  directory. 

Other  threats  (e.g..  malicious  corruption  of  directory  Information)  may  arise  from  the  broader  use  of  the 
directory,  however  these  are  outside  of  the  scope  of  the  X.400  base  standard  and  this  Implementors 
Agreement. 

Work  continues  within  CCiTT  and  ISO  to  improve  the  security  inherent  In  the  Directory  standards. 


E.3.5.11       Implications  for  conversion 

implementatk>n  of  the  Security  functional  group  may  additionally  either  require  that  any  conversion  facilities 
are  higNy  trusted  to  regenerate  the  appropriate  security  elements  (notably  the  content  Integrity  check)  or 
prohibit  the  use  of  conversion  within  the  MTS  altogether.  In  particular,  It  should  be  noted  that  use  of 
conversk>n  feciiities  will  invalidate  any  origin  authentication  t>ased  on  the  original  content. 


E.3.5.12  Accountability 

Accountability  depends  on  the  kientiflcatlon  and  authentication  of  users,  then  subsequent  records  being  kept 
on  the  actions  taken  by  users.  Therefore,  accountability  depends  on  all  the  relevant  Informatkxi  being 
property  stored  or  recorded. 

Accountability  features  provkJed  by  domains  (or  MTAs)  are  subject  to  bilateral  agreement  between  domains 
(or  MTAs)  and  may  optionally  provkie  non-repudiation  sen/ices.  Accountability  features  Include  pervasive 
mechanisms  such  as  security  logs,  audit  trails  and  archives,  or  they  may  be  mechanisms  supported  by 
protocol.  Protocols  to  support  accountability  will  be  subject  to  bilateral  agreement. 


E.3.5.13      Double  enveloping 

Double  enveloping  can  be  used  with  each  secure  messaging  security  dass.  For  each  security  dass  It  Is  an 
opttonal  extenston  to  the  security  features  which  can  be  used  to  counter  specific  vulnerabilities.  When 
double  enveloping  is  used.  It  shall  be  applied  at  the  boundary  of  a  domain,  and  obey  the  rules  of  an  MTA 
at  management  domain  boundaries.  Figure  24  illustrates  the  technique. 
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Outer  Envelope  2 


Content  2 


Inner  Envelope  1 


Content  1 


Figure  24  -  Double  enveloping  technique 


Address  information  in  envelope  1  and  2  are  not  necessarliy  the  same. 
Trace  information  in  envelope  1  and  2  are  not  necessarily  the  same. 

The  double  envelope  technique  can  be  used  in  1984  and  1988  MTS  environments.  Wfien  used  in  an  1988 
environment,  any  security  dass  can  be  applied  to  the  outer  envelope.  It  is  recommended  that  tlie  Inner  | 
envelope  is  encrypted.  When  the  dout)le  envelope  technique  is  used  as  a  secure  relay  path  via  an  1964 
domain,  any  encryption  of  the  content  2  is  subject  to  bilateral  agreement. 

Trace  information  is  not  passed  t)etween  Inner  and  outer  envelopes.  It  is  recommerKled  that  trace 
information  on  the  outer  envelope  is  always  archived  when  the  double  envelope  technique  is  used. 


E.4     Security  class  SO 
E.4.1  Rationale 

Security  dass  SO  is  confined  to  security  functionality  operating  between  MTS-Users  on  an  end-to-end  basis. 
It  is  designed  to  minimize  the  required  functionality  in  the  MTS  to  support  submission  of  elements  associated 
with  these  services.  Security  services  which  must  be  supported  (i.e.,  must  be  made  avaHable)  are  those 
which  are  considered  in  any  secure  messaging  environment.  I.e.: 

a)  Content  Integrity; 

b)  Message  Origin  Authentication  (end-to-end); 

c)  Proof  of  Delivery. 

Other  security  services,  such  as  Content  Confidentiality,  may  optionally  be  supported. 
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EAJ2      Technical  Implications 

The  technical  implications  for  security  dass  SO  are: 

a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  generate  the  signed,  signature  and 
encrypted  macros  on  message  sut>mission;  and, 

b)  it  is  necessary  to  provide  mechanisms  in  a  UA  which  can  handle  the  signed,  signature  and 
encrypted  macros  on  message  delivery. 

iE.5     Security  class  SI 
E.5.1  Rationale 

The  Si  security  dass  is  a  superset  of  security  dass  SO  and  introduces  the  basic  requirement  for  security 
[functionality  not  only  within  the  MTS-User  but  also  within  the  MTS.  This  security  functionality  within  the  MTS 
lis  designed  to  support  the  enforcement  of  a  security  policy  within  a  security  domain.  As  a  consequence, 
'S1  enables  trusted  routing  to  t>e  implemented. 


NOTE  -  The  level  of  trust  in  the  route  will  depend  on  the  level  of  trust  in  the  security  lat>el  and  security  context. 

IE.5.2      Technical  implications 

•i 

The  technical  implications  of  security  dass  SI  are: 

a)  It  is  necessary  to  provide  mechanisms  In  a  UA  which  can  generate  the  signed,  signature  and 
encrypted  macros  on  message  submission; 

b)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  handle  the  signed,  signature  and 
encrypted  macros  on  message  delivery; 

c)  it  is  necessary  to  provide  mechanisms  in  the  MTA  for  registration,  change-credentials  and  bind 
abstract  operations  (i.e.,  signed  macro  for  bind); 

d)  It  is  necessary  to  provide  mechanisms  in  the  MS  for  MS-registratlon  and  MS-bInd  operation  (i.e., 
signed  n^cro  for  MS-Bind); 

e)  It  is  necessary  to  support  message  security  labelling  (the  level  of  assurance  is  subject  to 
individual  security  domain  requirements); 

f)  It  is  necessary  that  reliable  access  is  always  supported; 

g)  It  is  necessary  for  the  MTAs  to  checi<  the  existence  of  the  security  elements  which  are  dassified 
as  'dynamic  mandatory"; 
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h)  It  is  necessary  to  provide  a  trusted  connection  t)etween  peers  to  provide  adequate 
confidentiality,  integrity  and  peer  entity  authentication. 


E.6     Security  class  S2 


E.6.1  Rationale 

Security  Class  S2  is  a  superset  of  Security  Class  Si .  It  eniiances  the  fecilities  of  the  MTAs  in  order  to  check 
tlie  origination  of  messages.  prot)es,  and  reports  within  the  MTS  and  to  provide  enhanced  integrity  checl(8 
on  the  security  label  while  in  the  MTS.  The  extra  security  services  provided  by  this  security  dass  can  help 
to  provide  trusted  routing  within  an  MTS. 

Addlttonally.  It  Is  possible  to  provide  non-repudiation  within  an  MTS. 


E.6.2      Technical  Implications 

The  extra  security  services  specified  by  Security  Class  S2  use  asymmetric  techniques  exclusively. 
The  technical  implications  are  as  In  Security  Class  Si.  plus: 

a)  It  is  necessary  to  provide  mechanisms  in  an  MTA  and  UA  thiat  can  process  the  signed  macro 
ol  certificates; 

b)  The  constraint  that  the  option  of  supporting  Content  Confidentiality  cannot  be  allowed  when  the 
message  origin  authentication  check  (MOAC)  is  used  to  provkJe  non-repudiation  services.  Under 
this  condition  Content  ConfkJentiality  is  not  supported.  If  the  MOAC  is  not  used  for  this  purpose, 
Content  Confkientiality  can  t)e  supported  as  an  optional  security  service; 

,    c)  It  Is  rtecessary  to  provkle  mechanisms  In  a  MTA  which  can  generate  and  process  the  signature 
macro  of  a  message,  probe,  and  report  authentication  check  (MOAC.  POAC  and  ROAC); 

d)  It  Is  necessary  to  provkle  mechanisms  in  a  UA  and  MTA  that  can  internee  with  an  X.500 
directory  supporting  the  Authentication  Framework  as  defined  in  X.509/ISO  9594-8  or  can  distrubute 
public  keys  by  other  trusted  means  which  is  compliant  with  X.509; 

e)  It  Is  necessary  to  provkle  a  trusted  means  of  generating  certificates; 

f)  It  Is  necessary  to  provkie  mechanisms  in  the  MTA  which  can  process  a  proof  of  submlsskxi 
request  and  generate  the  proof  of  submission  signature; 

g)  It  is  necessary  to  provkle  a  mechanism  In  an  MTA  which  will  generate  ROAC  signatures  with 
reports; 

h)  Connection  confkJentiality  is  only  provkJed  by  this  security  dass  when  the  message-origin- 
authentteation-check  is  computed  using  dear  content  to  provkle  non-repudiation  of  origin  security 
service  (i.e.,  non-repudiation  is  provkJed  only  on  the  dear  content  of  the  message); 
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i)  The  irrevocable  proof  required  to  provide  rK)n-repudiation  witliln  the  MTS  is  achieved  by  the 
management  of  asymmetric  keys.  The  explicit  definition  of  asymmetric  key  management  is  oUside 
the  scope  of  these  implementors  Agreements. 

E.7     Confidential  security  class  variants  (SOa,  SI  a,  and  S2a) 
E.7.1  Rationale 

[  These  security  dass  variants  are  supersets  of  SO,  Si ,  and  S2,  adding  the  requirement  for  support  of  erxJ-to- 
Jend  content  confidentiaiity.  The  rationale  for  these  variants  is  to  avoid  the  implementation  cost  and 
'I  processing  overiiead  involved  in  encrypting  the  entire  message  content  unless  there  Is  a  definite 
I  requirement.  It  Is  also  possible  to  protect  the  encryptton  techniques  and  mechanisms  (I.e.,  algorithms,  key 
^lengths,  key  versions,  etc.)  by  Secure  Access  Management. 

iE.7.2      Technical  implications 

The  technk^al  Implications  of  the  confMential  security  class  variants  are  the  same  as  those  for  tlie 
<  (Corresponding  primary  security  class,  plus: 

a)  It  Is  necessary  to  provkJe  mechanisms  In  a  UA  which  can  use  the  encrypted  macros  to  encrypt 
and  decrypt  the  message  content. 


I 
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)(^nex  G  (Informative) 


Defense  message  handling  profiles 


IG.I  Introduction 

r  Several  additional  requirements  for  Message  Handling  Systems  (MIHS)  in  tlie  U.S.  Department  of  Defense 
l(DoD)  are  curendy  being  investigated  by  the  Data  Ckimmunications  Protocol  Standards  (IXPS)  Technical 
Management  Panel  (DTMP).  Tills  annex  describes  the  DoD  Standardized  Profile(s)  (DSP)  that  are  required 
'jlor  Defense  Message  System  (DMS)  use. 


-  DSP  AMHIn(D)  -  Infomiation  Technology  -  Defense  Standardized  Profiles  AMHIn(D)  -  Message 
I         Handling  Systems  -  Common  DoD  Messaging 

j  -  DSP  AMH2n(D)  -  Information  Technology  -  Defense  Standardized  Profiles  AMHIn(D)  -  Message 
'         Handling  Systems  -  Military  Messaging 

^hese  prones  wW  be  published  as  part  of  the  MIL-STD-2045  series.  The  AMHI  n(D)  profile  consists  of  a  DoD 
delta  to  the  AMHIn  ISP.  AMH2n(D)  is  a  standalone  profile  of  a  new  military  messaging  content  type  (P772) 
based  on  the  IPM  content  type.  These  extensions  support  military-unique  functionality  required  by  the  DMS. 


DTMP  WG/2  Chalmnan 

c/o  Defense  infonnatlon  Systems  Agency  (DISA) 
Joint  InteroperabUity  Engineering  Offlce  (JIEO) 
Code  TBBD 

Fort  Monmouth.  NJ  07703-5000 
Phone:  908-532-7726 


'wo  multipart  DoD  profiles  are  cunently  defined,  namely: 


Ipor  further  information  on  these  profiles,  contact: 
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Differences  between  OIW  Agreements  and  EWOS/ETSI  Draft  Profile 

A/3312 

H.I  P7 

The  "and,"  "or."  and  "nof  elements  of  Filter  are  optional  in  A/3312. 

The  "equal,"  "greater-or-equai,"  "less-or-equai,"  and  "present"  elements  of  Filterltem  are  optional  in  A/3312; 
however,  at  least  one  must  be  implemented. 

The  List  and  Summarize  operations  are  optional  for  the  UA  Kernel  in  A/3312. 

The  "precise"  element  in  the  Fetch  operation  is  optional  for  the  UA  Kernel  in  A/3312. 
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redpient-reassignment-prohlbited  56, 58. 72. 73 
redirected  60,  61 
redirection-history  57-59.  74.  75 
redirectiorvreason  61.  78 
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g3-facsimile-bocly-parts  103 
g3-facsimile-data  103 
g3-facsimile-parameters  103 
g4-class1 -body-parts  103 
heading  102 
ia5-text-body-parts  103 
iaS-text-data  103 
iaS-text-parameters  103 
importance  102 
incomplete-copy  102 
intended-recipient-name  99 
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suppl-receipt-infb  103 

teletex-data  103 

teletex-parameters  103 

this-ipm  102 
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Part  9  -  File  Transfer,  Access  and  Management  Phase  2 

NOTE  -  In  document  type  names,  constraint  set  names,  and  abstract  syntax  definitions,  the  "NBS"  designation 
will  be  preserved. 


0  Introduction 

This  part  defines  Implementors'  Agreements  based  on  ISO  File  Transfer,  Access  and  Management  (FTAM), 
as  defined  in  ISO  8571.  This  intemationai  Standard  lias  four  parts.  Part  1  of  the  IS  gives  general  concepts, 
part  2  defines  the  Virtual  Filestore  (VFS).  part  3  defines  the  File  Service,  and  part  4  defines  the  File  Protocol. 

FTAM,  as  described  in  the  IS,  is  based  on  the  following  ISO  documents:  ACSE  Service  and  Protocol  (ISO 
8649.  ISO  8650),  Presentation  Service  and  Protocol  OSO  8822,  ISO  8823),  ASN.1  Abstract  Syntax  Notation 
and  Basic  Encoding  Rules  (ISO  8824.  ISO  8825),  and  Session  Service  and  Protocol  (ISO  8326,  ISO  8327). 
These  services  and  protocols  are  defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498).  These 
Agreements  provide  detailed  guidance  for  the  Implementor,  and  eliminate  ambiguities  in  interpretations. 

The  general  agreements  reached  with  respect  to  the  ISO  File  Transfer,  Access  and  Management  Protocol 
(FTAM)  are  that  the  Phase  2  FTAM  specification  (this  part)  Is  based  on  the  Intemationai  Standard  (IS). 


1  Scope 

These  FTMA  Phase  2  Agreements  cover  transfer  of  and  access  to  files  between  the  Filestores  of  two  end 
systems,  including  the  management  of  a  Virtual  Filestore.  One  erxJ  system  acts  in  the  Initiator  role  and 
initiates  the  file  transfer/access,  while  the  other  end  system  acts  in  the  Responder  role  and  provides  access 
to  the  file  in  the  Virtual  Filestore.  This  part  describes  Agreements  for  the  actions  and  attributes  of  the  Virtual 
Filestore,  and  the  service  provided  by  the  file  service  provider  to  file  service  users,  together  with  the 
necessary  communications  between  the  Initiator  and  Responder. 


Virtual 
Filestore 
2 


Real 
Filestore 
1 

End 
System  1 
-  Initiator  - 

End 
System  2 
-  Responder  - 

Real 
Filestore 
2 

Figure  1  -  Model  of  file  transfer/access. 


NOTE  -  Agreements  apply  on  the  double  lines  of  figure  1.  The  mapping  between  the  Virtual  Filestore  and 
the  Real  Filestore  together  vwth  the  local  data  management  system  is  not  part  of  these  Agreements. 

These  Agreements  define  general  Agreements  in  clauses  5  through  16,  minimum  functionality  (Conformant 
Implementations)  in  clause  17,  and  functionality  for  several  Implementation  Profiles  which  are  tailored  to 
different  classes  of  user  requirements  in  clauses  18  and  19. 
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2    Normative  References 

ISO  8571-1:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  1:  General  Introduction 

8571-2:  1988(E),  Infonruitlon  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management  Part  2:  Virtual  Flestore  Definition  ISO 

ISO  8571-3:  1988(E),  information  Processing  Systems  -  Open  Systems  Interconnection  -  FHe 
Transfer,  Access  and  Management  Part  3:  The  File  Service  Definition 

ISO  8571-4:  1988(E),  Infomnation  Processing  Systems  -  Open  Systems  interconnection  -  FHe 
Transfer,  Access  and  Management  Part  4:  The  File  Protocol  Specification 


3  Status 

Version  3  erf  the  FTAM  Phase  2  implementation  Agreements  was  completed  Decemt>er  15,  1989,  and 
put}iished  in  version  3  of  the  Stable  Implementation  Agreements  (NiST  Special  Publication  500-177, 
December  1989).  Some  editorial  clarifications  and  technical  changes  (due  to  international  harmonization 
of  Profiles)  were  added  to  Version  3  Agreements  in  the  course  of  1990.  All  these  changes  are  now  fully 
incorporated  in  this  version  4  of  the  RAM  Phase  2  Stat)le  Agreements. 

No  further  enhancements  will  be  made  to  this  version  4  of  RAM  Phase  2  (see  the  clause  4  ERRATA). 

This  version  4  of  the  RAM  Phase  2  Agreements  fully  replaces  the  version  3  as  published  in  NIST  SP  500- 
177.  Therefore,  the  old  version  3  of  RAM  Phase  2  will  no  longer  t>e  maintained. 

The  following  list  summarizes  the  technical  errata  changes  to  RAM  Phase  2,  Version  1  which  were 
incorporated  in  Version  2.  It  also  states  the  degree  of  possible  interworking  and  backward  compatibility  to 
RAM  Phase  2,  Version  1. 


Technical  Changes  in  FTAM  Phase  2, 
Version  2  (Dec.  '88) 

Backward  Compatibility  to  FTAM 
Phase  2,  Version  1  (Dec.  '87) 

1 .  Check  of  already  established 
presentation  contexts  for  a 
document  type  not  at  CREATE 
time  but  at  OPEN  time 

Interworking  problems  could  occur  when 
creating  a  document  type  which  is  not 
opened 

2.  Receivers  shall  not  require 
sending  of  AETtitles 

Interworking  problems  could  occur  if 
AETitles  are  not  sent 

3.  Minimum  requirement  for  FADU 
identities  for  document  types 
which  use  the  sequential  flat 
constraint  set 

Interworking  problems  could  occur  if  FADU 
identities  beyond  the  minimum  requirement 
are  used 
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The  following  list  summarizes  the  technical  errata  and  alignment  changes  which  were  incorporated  In  FTAM 
Phase  2,  Version  3.  It  also  states  the  degree  of  possible  interworking  and  t)acl<ward  compatibility  to  FTAM 
Phase  2,  Version  2. 


1  T«chnical  Changes  in  FTAM  Phas*  2, 
1  Varalon  3  (Dac.  '89) 

Backward  Compatibility  to  FTAM  | 
Phase  2.  Version  2  (Dec.  '88) 

1  1.  Unconstrained  Service  Class  outside 
1     the  scope  of  the  Implementation 
1  Profiles 

Full  compatibility,  since  change  only  from 
"optional"  "to  "outside  scope* 

1  2.  <contents-type-llst>  parameter 
1      Both  types  of  values  optional 
for  Initiators 

Full  compatibility,  since  this  clarification  is 
only  for  Initiators 

3.  Specification  of  supported  values  for 
<  override  >  parameter  in  F-CREATE 

Interworking  problems  may  occur,  if  different 
values  supported 

4.  Parameters  <filesize>,  <  future 
fileslze>,  <fadu-number>  maybe 
encoded  witli  up  to  8  contents 
octets 

Interworking  problems  may  occur,  since  no 
minimum  requirement  was  defined  ror 
Version  2. 

1  5.  For  NBS-7  and  NBS-8  in 
1      conjunction  with  T  or  TM 
1      Service  Class,  the  FADU 
1      identities  "current",  "next", 
1     "previous"  are  not  required 

Full  compatibility,  since  these  identities  were 
never  useful  in  conjunction  with  T  or  TM 
Service  Class 

1  6.  For  NBS-8  files  the  minimum  range 
for  l<eys  of  string-type  is  (1-16) 
Instead  of  (0-16) 

Interworking  problems  may  occur  for  key- 
length  parameter  0 

7.  Restriction  "NBS-9  files  may  not  be 
Created  or  Deleted"  removed  from 
the  document  type  definition.  But 
both  actions  are  outside  the  scope  of 
the  Agreements. 

Full  compatibility,  since  Creation,  Deletion 
was  never  in  the  scope  of  the  Agreements 

8.  Constraint  set  NBS-ordered-flat: 
1      The  location  after  an  Insert  is  "end" 

Full  compatibility,  since  this  specification  was 
already  implicitly  clear 
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4  Errata 


1     NO.  OF 
1  ERRATA 

TYPE 

REFERENCED 
DOCUMENT 

CLAUSE 

CP  3/91-1 

EDITORIAL 

NIST-SP  500-183 

All 

Update  to  ISO  style. 
General  formatting  and 
error  corrections. 
Alignment  with  the 
wording  of  the  ISP. 
Consistent  naming 
conventions. 

CP  9/91-1 
CP  9/91-2 

EDITORIAL 

NIST-SP  500-183 

Table  9 
Table  10 
Table  11 

Datatypel  ASN.1 
comment  to  use  the 
object  descriptor 

CP  9/91-3 
CP  9/91-4 

Clause  17 
Annex  A 

Include  Corrigenda 

Editors  note  to  point  at 
ISP  for  registered 
objects. 

CP  9/91-5 
CP  9/91-6 

A.5.11.1 
A.6.11.1 

A.7.7 
A.7.9.1 
A.7.9.2 

Change  header  to 
Structural  Simplification. 

Added  definitions  for 
Datatype3 

5  Assumptions 

FTAM  protocol  machines  must  be  able  to  parse  and  process  at  a  minimum  7K  octets  of  FTAM  PCI,  FTAM 
structuring  (FTAM-FADU)  and  RAM  user  data  (including  grouped  FPDUs)  as  they  would  be  encoded  with  * 
the  ASN.1  Basic  Encoding  Rules.  It  is  recommended,  however,  that  Presentation  user  data  not  be  restricted 
in  size.  I 

I 

In  order  to  maximize  interoperability,  it  is  important  that  the  implementations  of  FTAM  service  providers  do  | 
not  unnecessarily  restrict  the  service  user's  ability  to  generate  arbitrary  file  service  requests.  OthenA/ise,  they  i 
may  not  be  able  to  work  with  FTAM  Responders  whose  operation  is  constrained  by  their  mapping  of  the  S 
FTAM  Virtual  Filestore  to  their  local  filestore.  For  example,  error  procedures  should  only  be  invoked  when 
an  error  actually  occurs,  not  at  the  point  of  the  specification  of  options  which  might  result  in  an  error.  i 

implementations  must  be  able  to  parse  all  valkl  optional  parameters  if  they  are  present  in  the  PDU.  Only 

those  optional  parameters  specified  as  supported  in  these  Agreements  are  required  to  t>e  implemented.  If  ' 

these  parameters  are  not  present,  a  default  value  is  assigned  locally.  A  Responder  should  not  refuse  a  > 

request  solely  because  a  parameter  that  is  optional  in  the  FTAM  standard,  but  is  supported  in  these  i 
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Agreements,  Is  not  present. 

Consideration  of  any  standardized  service  interface  is  not  covered  by  these  Agreements. 

These  Agreements  define  no  restrictions  for  the  vaiues  used  for  the  <  communication  quaiity  of  service  > 
parameter  in  <F-INiTiAUZE>. 

FTAM  is  defined  in  phases.  The  Phase  1  FTAM  implementation  specification  is  based  on  the  second  ISO 
Draft  Proposal,  dated  April  1985,  and  the  ISO  Draft  Proposal  8824  and  8825. 

The  Phase  2  FTAM  specification  (this  part)  is  based  on  the  Intemational  Standard  (IS).  THERE  IS  NO 
BACKWARD  COMPATIBIUTY  WITH  FTAM  PHASE  1.  Backward  compatibility  is  impossible,  since  Phase 
1  uses  Session  services  directly,  while  Phase  2  uses  ACSE  and  Presentation  services.  FurthemrKxe,  there 
are  differences  in  Filestore,  PDU  Abstract  Syntax,  FADU  Abstract  Syntax,  and  Transfer  Syntax.  There  also 
are  differences  in  the  transparency  mechanisms  and  service  class  negotiations. 

The  <  implementation  infonTiation>  parameter  of  <F-INITIAUZE>  FPDU  as  defined  in  ISO  8571-4,  20.3  Is 
used  to  pass  'user  version"  information  with  respect  to  different  FTAM  phases  of  the  OSI  Implementors' 
Agreements  or  with  respect  to  FTAM  profiles  of  other  bodies  (see  clause  12).  It  is  the  goal  of  these 
Agreements  to  use  the  "user  version"  mechanism  to  provide  at  least  one  level  of  backward  compatibility  for 
all  future  FTAM  Phases,  facilitating  backward  compatibility  for  future  FTAM  products,  assuming  different  new 
versions  of  the  respective  IS's  also  enable  backward  compatibility. 

The  FTAM  specific  ASE  requirements  for  ACSE  in  the  Upper  Layers  part  of  this  document  define  a  value 
(that  canies  no  semantics)  for  the  AETitle  that  can  be  used  by  FTAM  ASEs  for  communication.  Other  values 
for  the  AETitle  are  outside  the  scope  of  these  Agreements. 

The  association  shall  not  be  rejected/aborted  if  any  of  the  following  parameters  either  contains  the  defined 
value  or  is  not  sent: 

(Called  -  AETitle 

Calling  -  AETitle 

Responding  -  AETitle 

The  association  may  t>e  rejected /aborted  if  any  of  these  parameters  contain  other  values. 

Use  of  values  outside  the  scope  of  these  Agreements  is  discouraged  until  agreed  upon  semantics  have  been 
associated  with  AETIttes. 

Use  of  <  shared  ASE  infomiation>  parameter  and  <  charging  >  parameter  is  not  defined  within  the  scope 
of  the  Agreements. 

Use  of  <  application  context  name>  parameter  is  not  defined  within  the  scope  of  these  Agreements.  This 
parameter  does  not  prohibit  the  establishment  of  an  FTAM  association. 

These  Agreement  use  the  term  "supported"  for  a  parameter  to  mean  that  the  syntax  and  semantics  of  that 
parameter  shall  be  implemented.  However,  it  is  not  a  requirement  that  the  parameter  be  used  in  all 
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Instances  of  communication,  unless  stated  othenA/lse. 

Also  these  Agreements  use  the  temi  "optionally  supported"  for  a  parameter  to  mean  that  It  is  left  to  the 
implementation  whether  the  semantics  of  that  parameter  are  implemented  or  not. 

6  Presentation  agreements 

The  following  Abstract  Syntaxes  are  recognized  in  these  Agreements: 
"RAM  FADU" 
"FTAM  PCI" 

"FTAM  unstructured  text  abstract  syntax" 

"FTAM  unstructured  binary  abstract  syntax" 

"NBS  abstract  syntax  AS1" 

"NBS  file  directory  entry  abstract  syntax" 
The  following  Transfer  Syntax  is  supported: 

"Basic  Encoding  of  a  single  ASN.1  type" 
See  also  annex  C. 

7  Service  class  agreements 

implementation  Agreements  have  been  reached  for  the  following  service  classes: 
File  Transfer 
File  Access 
File  Management 
File  Transfer  and  Management 
Unconstrained 
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8  Functional  unit  agreements 

Implementation  Agreements  have  been  reached  for  the  following  functional  units: 
Kernel 
Read 
Write 

File  Access 

Limited  File  Management 
Enhanced  File  Management 
Grouping 

Implementation  of  the  Recovery,  Restart  Data  Transfer,  and  FADU  Locking  functional  units  is  not  specified. 

9  File  attribute  agreements 

implementation  of  the  Kernel  Group  of  file  attributes  is  defined.  If  the  optional  Storage  Group  and  Security 
Group  are  implemented,  aspects  of  their  implementation  are  defined.  Implementation  of  the  Private  Group 
is  not  specified. 

Responses  to  an  attribute  value  request  shall  always  include  one  of  the  foilowing  (as  specified  In  ISO  8571-2, 
clause  4): 

An  actual  file  attribute  value. 

A  value  indicating  that  no  value  is  available,  optionally  with  a  diagnostic. 

No  value  and  an  error  code,  optionally  with  a  diagnostic  indicating  that  the  attribute  is  not 
supported. 

9.1      Mandatory  group 

Only  the  Kemel  Group  of  attributes  is  required.  A  value  for  < filename  >,  <  permitted  actions >,  and 
<  contents  type>  will  always  be  availat>le. 

A  minimum  range  is  required  for  <filename>  values  as  specified  in  ISO  8571-2.  No  maximum  length  or 
format  restrictions  apply.  A  system  that  does  not  support  <filename>  values  with  a  sequence  of  more  than 
one  Graphic  String  or  extended  <  filename  >  characteristics  may  reject  a  request  involving  such  a 
<filename>.  All  systems  must  be  able  to  interpret  a  <filename>  value  with  a  sequence  of  one  Graphic 
String. 
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A  Responder  shall  not  require  an  Initiator  to  use  multiple  component  Graphic  String  filenames.  Requests 
using  a  single  component  <flename>  value  with  a  sequence  of  one  Graphic  String  shall  t>e  responded  to 
using  a  single  component  <filename>  value.  Responses  to  requests  Involving  <fMename>  values  having 
two  or  more  Graphic  Strings  are  not  defined  here  but  may  be  interpreted  via  bHaterai  or  other  external 
agreements.  Use  of  <  filename  >  values  with  a  Mquence  of  more  than  one  Graphic  String  Is  discouraged. 

Apart  from  the  minimum  conformance  requirements  specified  In  ISO  8571  -2.  file  names  have  to  be  specified 
In  ttie  naming  convention  of  the  responding  FTAM  Implementation.  It  is  a  local  Implementation  matter  of 
the  FTAM  Responder.  whether  or  not  an  additional  name  mapping  onto  the  real  Filestore's  file  name 
convention  is  supported. 

In  order  to  enable  interworking  with  all  FTAM  Responders'  virtual  Flestores,  It  Is  recommended  that  FTAM 
Initiators  impose  no  restrictions  on  the  attribute  range  supported  for  file  names  beyond  those  specified  in 
ISO  8571-2. 

For  the  purpose  of  interworking  according  to  these  Agreements  the  <  contents  type>  attrit>ute  Is  limited  to 
the  <  document  type  name>  fonnat.  The  <  constraint  set  name.  at)stract  syntax  name>  form  is  outsMe  the 
scope  of  these  Agreements.  It  shouki  always  be  parsed  correctly  when  received,  but  may  result  in  an  en-or. 


9.2     Optional  groups 

If  the  optional  Security  Group  of  file  attributes  Is  Implemented,  an  actual  value  must  be  available  for  the 
<  access  control  >  attribute. 

The  <  access  control  >  attribute  Is  a  SET  OF  <  access  control  element  >.  The  minimum  requirement  In  these 
Agreements  is  the  support  of  one  <  access  control  element  >.  according  to  the  base  standard.  The  terms 
<concun'ency  access> .  < kientity > .  and  < passwords>  are  each  opttonaliy  supported.  Details  of  their  use 
shall  be  specified  in  the  PICS.  Use  of  the  <locatk>n>  term  Is  not  specified  in  these  Agreements. 

Implementation  of  the  Private  Group  is  not  specified. 


10  Document  type  agreements 

These  document  types  are  defined: 

FTAM-1  "ISO  FTAM  unstmctured  text" 

FTAM-2  "ISO  FTAM  sequential  texT 

FTAM-3  "ISO  FTAM  unstmctured  binary" 

NBS-6  'NBS-6  FTAM  sequential  file' 
NBS-7  "NBS-7  FTAM  random  access  file" 
NBS-8  "NBS-8  FTAM  Indexed  file' 
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NBS-9  'NBS-g  FTAM  file  directory  file' 

DetaHed  document  type  definitions  are  given  In  annex  A  and  In  ISO  8571-2,  annex  B. 

NOTE  -  Document  types  NBS-1  to  NBS-5  are  not  defined  in  these  Agreements.  The  numbering  starts  with 
NBS-6  t>ecau8e  of  the  original  DIS  version  of  these  Agreements. 

An  Implementation  claiming  conformance  to  these  Agreements  which  also  supports  any  or  all  of  the 
document  types  FTAM-1,  FTAM-2.  and  FTAM-3  as  defined  in  ISO  8571-2,  annex  B.  must  minimally  support 
the  comt>inations  of  parameter  values  as  specified  In  table  1 


Table  1  -  Parameters  for  FTAM-1,  -2,  -3 


Universal 
Class  Number 

Maximum 
String  Length*'^ 

String  1 
Significance 

FTAM-I 

General  String  \27) 
lASString  ''(22) 

134  or  less 

'not-significanf* 

FTAM-a 

Graphic  String  ''^(25) 

134  or  less' 

'not-significanf' 

FTAM-3 

<not  applicable  > 

512  or  less 

'not-significant'^ 

NOTES 

1  The  minimum  level  of  support  for  General  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  character  sets,  and  ISO  646,  IRV  CO  set. 

2  The  support  for  IA5  String  is  the  ISO  646,  IRV  GO  character  set  and  the  ISO  646,  IRV  CO  set. 

3  The  minimum  level  of  support  for  Graphic  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  sets. 

4  This  is  the  default  when  the  parameter  is  not  specified. 

5  The  implementation  need  not  support  Data  Units  v«4iose  total  character  count  exceeds  134. 

6  As  per  table  3. 

7  The  length  refers  to  the  number  of  characters  from  the  applicable  character  set.  It  does  not  include  any 
escape  sequences  or  overhead  from  the  encoding. 

8  If  escape  sequences  are  used  in  the  encoding  of  the  data  and  string  boundaries  are  not  maintained  when 
the  file  is  stored,  it  may  be  necessary  for  the  escape  sequences  to  occur  at  different  locations  wtien  the  file 
is  re-sent. 

For  document  types  which  use  the  sequential  flat  constraint  set,  conformant  implementations  must 
minimally  support  FADU  identities  as  follows: 

for  Transfer  service  class:  "begin,"  "end" 
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for  Transfer  and  Management  sendee  dass:      "begin."  "end" 

for  Access  service  dass:  "begin,"  "end."  "first."  "next" 

For  the  document  types  NBS-7  and  NBS-8  used  in  conjunction  with  the  Transfer  service  dass  or  the 
Transfer  and  Management  service  dass.  the  support  of  the  FADU  identities  of  'current',  'next'  and  'previous' 
and  for  NBS-8  the  support  of  the  FADU  identity  of  'end'  are  outside  the  scope  of  these  Agreements. 

For  the  document  types  NBS-6.  NBS-7  and  NBS-8  parameters  are  used  for  which  the  Agreements  apply  as 
specified  in  table  2. 


Table  2  •  Parameters  for  NBS-6,  NBS-7,  NBS-8 


ParwiMlar 

Prim  Type 

String-length 

Length-1 

Length-2  | 

int 

INTEGER 

Number  of  octets 
required  to  represent,  in 
2's  complement  format, 
ine  largesi  imeger  to  ue 
passed 

t>it 

BIT  STRING 

Numkier  of  bits  in  string 
^^o^rva^yl^y^ 

iaS 

IA5STRING 

Max  number  of 
characters  in  string 

graphic 

Graphic  String 

Max  numt>er  of 
characters  in  string 

general 

General  String 

Max  number  of 
characters  in  string 

octet 

OCTET  STRING 

Max  numt>er  of  octets  in 
string 

private-  class- 
number 

Floating  Point 
Uumber 

The  minimum 
numtier  of  bits 
required  to  be 
maintained  in  the 
mantissa  for  relative 
precision 

Number  of  bits  | 
required  to  1 
represent  the 
largest  unbiased 
integer  exponent 
in  2's  complement 

univer-time 

UTCTime 

<not  applicable  > 

gen-time 

Ger>eralized  Time 

<not  appticat>le> 

txwiean 

BOOLEAN 

<not  applicable> 

nuH 

NULL 

<not  applicat}le> 

NOTE  •  Ttie  string  length  parameter  specifies  the  actual  numt)er  of  from  ttie  referenced  character  set.  It  does 
rwft  include  any  escape  sequences  or  overhead  from  the  encoding. 
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The  primitive  data  types  and  minimal  size  ranges  that  an  Implementation  must  accept  for  storage  are  given 
in  table  3. 


Table  3  -  FTAM  primMv  data  typea 


Primitiv*  Data  Typa 

Minimum  Rang*  (Octets)  1 

ASN.1  INTEGER 

1  -2 

ASN.1    BIT  STRING 

0-1 

ASN.1  lASString 

0-134 

1  ASN.1  GeneralString 

0-134 

1  ASN.1  GraphicString 

0-134 

1  ASN.1    OCTET  STRING 

0-512 

1  ASN.1  BOOLEAN 

ASN.1  NULL 

ASN.1  GeneralizedTime 

ASN.1  UniversaTTime 

NBS-AS1  FioatingPointNumber 

mantissa  1-23  bits  | 

exponent  0-8  bits  { 

NOTES 

1  The  primitive  data  types  and  their  maximum  ranges  for  a  specific  file  as  described  by  tfie  parameters  above 
are  maintained  In  the  <  contents  type>  file  attribute.  The  <  contents  type>  file  attribute  value  Is  established 
at  the  file's  creation  and  cannot  be  changed  via  FTAM  for  the  life  of  the  file.  This  Implies  that  the  data  element 
types  ar>d  ranges  and  data  unit  formats  are  fixed  for  all  accessors  of  that  file  as  long  as  the  file  exists. 

2  The  syntax  for  floating  point  numbers  Is  part  of  the  definition  of  NBS  abstract  syntax  AS1  in  annex  C.3.  It 
is  derived  from  existing  standards  lEC  559  and  IEEE  754. 


10.1    Character  set 

Implementation  of  a  character  set  In  FTAM  Is  understood  as: 
a  transfer  syntax  Is  defined  for  the  character  set 

document  types  are  defined  using  the  character  set  In  their  abstract  syntactic  definition 

documents  of  those  types  are  stored  In  the  Virtual  File  Store  as  defined  in  the  character  set 
specification.  They  are  written  into  the  VFS  and  read  from  the  VFS  as  defined  by  the  abstract 
syntax  and  the  transfer  syntax  for  the  document  type.  It  Is  not  In  the  scope  of  FTAM  Agreements 
to  specify  the  local  representation  of  those  documents  In  the  Real  Filestore,  nor  to  specify  rendition 
of  graphic  characters  or  control  characters  on  character  imaging  devices.  These  renditions  are 
possible  agreements  between  applications  using  FTAM  for  their  communication. 

The  character  sets  ISO  646.  IRV  and  ISO  8859-1  shall  always  be  implemented. 
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1 0.1 .1      ISO  646  Character  set 

The  international  Reference  Version  (iRV)  of  iSO  646  is  available  for  use  wtien  there  is  no  requirement  to 
use  a  national  or  an  application-oriented  version,  in  information  Interchange,  the  IRV  is  assumed  unless  a 
particular  agreement  exists  between  sender  and  receiver  of  the  data.  The  graphic  characters  allocated  to 
the  IRV  are  as  specified  in  table  4. 


Table  4  -  IRV  graphic  character  allocationa 


Graphic 

Nam* 

Codad  Rapraaantation  | 

# 

Number  sign 

2/3  1 

0 

Currency  sign 

2/4 

@ 

Commercial  at 

4/0 

[ 

Left  square  bracket 

5/11 

\ 

Reverse  solidus 

5/12 

] 

Right  square  bracket 

5/13 

y\ 

Circumflex  accent 

5/14 

t 

Grave  accent 

6/0 

{ 

Left  curly  bracket 

7/11 

1 

Vertical  line 

7/12 

} 

Right  curly  bracket 

7/13 

Tilde,  overline 

7/14 

It  should  t>e  noted  that  no  substitution  is  allowed  when  using  the  IRV  and  that  the  facility  of  comt}ined 
vertical  and  horizontal  movements  of  the  active  position  does  not  apply  to  any  format  effectors. 

It  is  permitted  to  use  composite  graphic  characters  and  there  is  no  limit  to  their  number.  Because  of  this 
freedom,  their  processing  and  imaging  may  cause  difficulties  at  the  receiving  end.  Therefore  agreement 
between  sender  and  receiver  of  the  data  is  recommended  if  composite  characters  are  used. 

NOTE  -  Attention  Is  drawn  to  the  fact  that  different  national  character  sets  exist. 

(See  ISO  646  or  CCITT  Recommendation  T.50  for  more  infonnation) 

1 0.1 .2     Format  effectors 

When  a  single  format  effector  for  vertical  (or  horizontal)  movement  is  optionally  penDitted  to  effect  a 
combined  vertical  and  horizontal  movement,  implementations  shall  not  use  the  single  format  effector  for 
effecting  the  combined  vertical  and  horizontal  movement.  It  is  recommended  that  OSI  Implementations  use 
<CR><LF>  pairs  as  line  terminators.    Failure  to  follow  this  recommendation  may  result  in  an 
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implementation  which  does  not  interoperate  with  other  implementations  confonning  to  these  agreements. 


1  For  further  information  see  ISO  646:1963.  clauses  4.1.22  and  6.4,  ISO  6429:1968,  clause  E.1.2  and  ISO 
4873:1986.  clause  A.3.2. 

2  The  Agreements  require  only  support  of  CO  control  characters  of  ISO  646.  containing  among  others  ttie 
format  effectors  <CR>  and  <LF>. 


10.1.3     8859-1  Character  set 

The  Latin  Alphabet  No.l  QSO  8859-1)  is  used  to  specify  the  printat)le  characters  of  GO  and  G1 .  CO  control 
characters  and  their  associated  rules  are  taken  from  the  ISO  646  definition. 


10.2    Document  type  Negotiation  ruies 


10.2.1     Connection  establishment 

in  connection  estatjiishment  the  <  contents  type  list>  parameter  is  used  only  to  establish  presentation 
contexts.  Both  the  <  document  type  name>  form  and  the  <  abstract  syntax  name>  fonn  are  supported  for 
Responders;  they  are  optionally  supported  for  Initiators. 


NOTES 
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10.2.2     File  creation 

An  <F-CREATE  request>  FPDU  must  contain  a  <clocument  type  name>  value  in  its  < initial  attributes> 
parameter. 

If  the  specified  document  type  requires  parameterization,  tiien  these  parameters  must  be  supplied,  othenwise 
the  <F-CREATE  request  >  may  be  rejected. 

NOTES 

1  It  is  understood  that  <  permitted  actions  >  sub-field  of  <  initial  attributes  >  parameter  will  always  be  used  at 
<F-CREATE  request  >.  The  value  may  be  changed  by  the  Responder. 

2  If  the  <  document  type  name>  used  requires  DU  syntax  parameters  and  one  of  the  parameters  specifies  ^ 
'FloatingPointNumber'  as  a  primitive  data  type,  the  request  may  be  rejected,  in  case  the  optional  type  ' 
'FloatingPointN umber"  is  not  supported  by  the  Responder. 


10.2.3     File  opening 

The  <  document  type  name>  form  (with  appropriate  parameters  as  specified  in  8871-2,  clause  12.3)  shall 
always  be  used  when  proposing  a  <  contents  type>;  as  an  alternative  the  'ContentsTypeUnknown'  value 
may  be  used  in  the  <F-OPEN  request>.  An  <F-OPEN  response>  shall  use  the  <document  type  name> 
option  (with  appropriate  parameters)  in  the  <  contents  type>  field. 

This  allows  the  receiving  entity  to  use  the  <  document  type  name>  attributed  to  the  file  instead  of  receiving 
a  <  constraint  set  name>  and  <  abstract  syntax  name>  pair,  which  does  not  reflect  the  file  information 
contained  in  the  FTAM  and  NBS  document  types. 

This  document  type  name  is  either  a  value  from  the  set  of  base  document  type  names  as  negotiated  upon 
connection  establishment  or  a  document  type  name,  for  which  an  appropriate  presentation  context  was 
established. 

NOTES 

1  An  <F-OPEN  response  >  without  a  <  document  type  name  >  (but  carrying  the  <  constraint  set  name>  and 
<at}stract  syntax  name>  form)  may  cause  the  Initiator  to  issue  an  <F-CLOSE  request>. 

2  If  the  <  document  type  name>  used  requires  DU  syntax  parameters  and  one  of  the  parameters  specifies 
'FloatingPointNumber*  as  a  primitive  data  type,  the  request  may  be  rejected,  in  case  the  optional  type 
'FloatingPointNumber*  is  not  supported  by  the  Responder. 
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10.3    Relationship  between  DUs,  DEs  and  document  types 

'Abetnict  Syntax"  is  used  to  refer  to  the  syntactic  information  which  is  archltecturaliy  passed  t>etween  the 
Application  and  Presentation  layers.  The  Abstract  Syntax  defines  Data  Eiement  (DE)  types  which  are  not 
neoessarly  ASN.1  primitive  types.  A  Data  Eiement  (DE)  is  the  smailest  piece  of  data  whose  identity  is 
necessarly  preserved  by  the  Presentation  Service.  Data  types  may  be  made  up  of  other  data  types.  Data 
Elements  are  not  defined  in  terms  of  other  Data  Elements. 

A  Data  Unit  PU)  is  a  sequence  of  one  or  more  Data  Elements.  Archltecturaily.  entire,  single  DEs  are  passed 
into  and  out  of  the  application  process,  in  a  real  implementation,  DUs  may  be  passed. 

To  maintain  DU  boundaries  during  transfer,  file  structuring  information  must  be  passed  (iS08571-FADU 
definition  in  ISO  8571-2,  clause  7.5).  A  Data  Element  is  referred  to  as  a  Fle-Contents-  Data-Element  in  the 
1806671 -FADU  definition. 

Document  types  refer  to  aspects  of  local  processing  and  storage.  They  describe: 
stru^urai  relationship  between  DUs, 
structure  of  DUs,  called  DU  syntax,  and 
DE  types  found  in  the  file 

Because  document  types  pertain  to  local  processing  and  storage,  the  DU  syntax  maices  assertions  about 
the  syntax  and  the  size  of  DUs  (records)  in  storage.  Parameters  on  the  document  types  provide  this 
information  about  the  syntax  and  size  of  the  DUs. 


11   F-CANCEL  action 

When  an  F-CANCEL  is  .sent  or  received,  the  following  occurs: 
no  more  data  is  sent, 
checkpoint  numbers  are  removed,  and 
state  of  the  file  is  implementation  dependent. 

NOTE  -  When  mapping  F-CANCEL  on  P-RESYNCHRONIZE  (abandon)  it  is  required  that  P-SYNC-MINOR  be 
used  after  F-READ/  F-WRITE  (see  ISO  8571-4  clauses  13. 14). 
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12  Implementation  information  agreements 

The  <  implementation  infomiation>  parameter  of  <F-INiTIALiZE>  FPDU  is  not  required  by  tiiese 
Agreements. 

It  may  be  used  to  pass  user  version  information  as  a  series  of  values,  separated  by 
The  following  will  indicate  conformance  to  the  Phase  2  Agreements:  NBS-Phase2. 

NOTE  -  The  list  of  possible  values  may  be  enlarged  for  future  FTAM  phases  or  FTAM  profiles  of  other  bodies. 
This  parameter  Is  for  information  only;  it  is  not  used  for  negotiation. 

The  establishment  of  an  FTAM  regime  should  not  be  rejected  only  because  of  an  unknown  <  Implementation 
information  >  value. 


13  Diagnostic  agreements 

The  <dlagnostic>  parameter  is  supported;  a  value  in  the  <response>  PDU  is  needed  when  the  <action 
result >  or  < state  result >  is  not  zero.  (The  nature  of  these  agreements  is  to  provide  <diagnostic> 
Information  when  any  result  parameter  is  not  "success.") 

General  catch-all  diagnostic  action  Is  discouraged. 

The  <furtlier  details>  subfield  is  supported.  It  will  be  encoded  as  GraphicString,  but  is  restricted  to  ISO  646 
(IRV,  graphic  characters)  and  ISO  8859-1  only. 

Use  of  F-P-ABORT  for  other  than  protocol  errors  and  catastrophic  situations  is  discouraged. 
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When  returning  an  error  status  in  a  fiie  management  related  diagnostic  (i.e.,  <F-READ-ATTRIBUTE 
response>  or  <F-CHANGE-ATTRiBUTE  response>).  identify  tiie  erroneous  attribute  by  using  tlie  first  two 
cfiaracters  of  <furttier  detaiis>  to  hold  a  2-digit  number  (encoded  as  lASString)  from  tf>e 
<F-READ-ATTRIB(JTE  request>  attributes  abstract  syntax  definition  (iSO  8571-4,  dause  20.3). 


nn 

rnoi  icliiic 

U1 

reiiiiiueu  MClions 

02 

Contents  Type 

03 

Storage  Account 

04 

Date  and  Time  of  Creation 

05 

Date  and  Time  of  l^st  Modification 

06 

Date  and  Time  of  Last  Read  Access 

07 

Date  and  Time  of  Last  Attribute  Modification 

08 

Identity  of  Creator 

09 

Identity  of  l-ast  Modifier 

10 

Identity  of  Last  Reader 

11 

Identity  of  Last  Attribute  Modifier 

12 

File  Availability 

13 

File  Size 

14 

Future  Filesize 

15 

Access  Control 

16 

Legal  Qualifications 

17 

Private  Use 

The  set  of  file  management  diagnostics,  found  in  ISO  8571-3  annex  A.  must  be  supported. 
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In  the  case  where  a  specific  parameter  can  in  no  way  be  accommodated  then  the  request  fails  and  a 
<diagnostic>  Indicating  one  such  parameter  should  be  returned  by  the  responder.  In  the  case  where  a 
negotiable  parameter  cannot  be  accommodated  with  exactly  the  value  requested  but  Is  negotiated  to  a 
different  value  (as  defined  In  the  standard)  then  the  request  formally  succeeds  but  informative  <diagnostics> 
indicating  those  parameters  negotiated  should  be  retumed. 

In  order  to  provide  for  robust  applications  using  FTAM,  well  defined  and  precise  diagnostics  are  required 
to  be  retumed  by  responding  implementations  whenever  an  action  cannot  be  carried  out  precisely  as  t 
requested  with  respect  to  non-negotiable  parameters.  All  such  applicable  diagnostics  will  be  returned  in  .I 
those  cases.  An  action  is  carried  out  precisely  as  requested  with  respect  to  a  parameter  when  the  value  i 
of  that  parameter  on  the  <  request  >  FPDU  is  equal  to  the  value  in  effect  during  or  subsequent  to  the  action, 
depending  on  whether  the  action  is  regime  control. 

Diagnostics  exist  to  signal  "parameter  not  supported"  and  Responder  implementations  shall  issue  all 
appropriate  diagnostics.  The  < further  details >  subfield  of  the  <diagnostic>  parameter  shall  specify  the 
parameter  which  is  not  implemented. 

14  Concurrency 

The  <  concurrency  control  >  used  by  default  on  actions  requested  by  an  <F-SELECT  indication  >  or  <F- 
CREATE  Indication  >  service  are: 

"shared"  for  read  and  read  attribute 

"exclusive"  for  all  other  actions 

The  default  for  actions  not  requested  is  specified  as  'not  required'  as  per  ISO  8571-3. 

NOTE  -  A  local  implementation  may  choose  to  be  more  restrictive  in  order  to  assure  file  consistency  for 
concurrent  accessors. 

FADU  locking  is  not  required. 
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15  Requested  access 

The  <  requested  access  >  parameter  on  <F-SELECT>  or  <F-CREATE>  is  used  to  specify  the  actions  which 
the  Initiator  may  perform  during  the  file  selection.  The  value  of  the  <  requested  access  >  parameter  is 
compared  by  the  Responder  to  the  <  access  control  >  and  <  permitted  actions  >  file  attributes  and 
concurrency  controls  (including  those  requested  by  the  Initiator)  currently  in  place  on  the  file.  If  the  value 
of  the  <  requested  access  >  parameter  is  not  consistent  with  either  <  access  control  > ,  <  permitted  actions  > , 
or  concurrency  controls  in  place,  then  the  <F-SELECT>  or  <F-CREATE>  must  be  rejected. 

< requested  access >  is  consistent  with  < access  control  >  if,  for  each  action  requested,  that  action  either 
requires  no  password,  or  the  required  password  has  been  specified  on  the  <F-SELECT  request >  or  <F- 
CREATE  request  >. 

<  requested  access  >  is  consistent  with  <  permitted  actions  >  if,  for  each  action  requested,  that  action  is 
allowed  by  the  <  permitted  actions  >  file  attribute. 

<  requested  access >  is  consistent  with  <  concurrency  control  >  requested  on  the  <F-SELECT>  or  <F- 
CREATE>  if,  for  each  action  requested,  that  action  has  not  been  specified  as  "not  required"  or  "no  access" 
in  the  <  concurrency  control  >  parameter. 

<  requested  access  >  is  consistent  with  concurrency  controls  in  place  on  the  file  If  for  each  action  requested 
no  other  accessor  of  the  file  has  set  the  concurrency  control  for  that  action  to  either  "exclusive"  or  "no 
access." 


16  Security 


16.1  Initiator  identity  and  filestore  password 

The  < initiator  identity >  and  <filestore  password >  parameters  for  an  implementation  acting  as  an  Initiator 
are  supported.  These  parameters  are  optional  for  an  implementation  acting  as  a  Responder. 

The  syntax  of  < initiator  identity >  and  <filestore  password  >  is  system-dependent.  <  initiator  identity >  and 
<filestore  password  >  will  represent  account  information  on  the  local  system,  which  may  be  different  from 
the  <  account  >  parameter. 

16.2  Access  passwords 

The  <access  passwords >  and  < create  password  >  parameters  for  an  implementation  acting  as  an  Initiator 
are  supported  if  the  Security  Group  of  attributes  is  supported.  These  parameters  for  an  implementation 
acting  as  a  Responder  are  optionally  supported  if  the  Security  Group  is  supported. 
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16.3    Implementation  responsibilities 

It  is  the  responsit>ility  of  each  local  system  to  provide  security  for  its  own  real  filestore.  Encryption  of 
passwords  will  not  be  done  by  FTAM. 

A  user  of  the  file  service  must  be  i<nown  by  the  Responder.  'Known*  is  defined  by  the  local  Filestore,  and 
Is  dependent  on  the  level  of  security  provided  by  the  local  Filestore. 


17  Requirement  for  conformant  implementations 

This  clause  gives  the  criteria  to  be  satisfied  by  every  implementation  of  FTAM  that  corrforms  to  these 
Agreements. 
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Conformance  to  these  Agreements  is  stated  in  tenns  of  the  different  roles  occupied  by  FTAM 
implementations.  The  interoperability  of  certain  configurations  of  these  roles  motivates  this  approach. 
Interoperable  configurations  of  these  roles  are  given  in  17.1. 

The  only  function  provided  by  every  conformant  implementation  is  the  transfer  of  unstructured  t>inary  files 
in  their  entirety.  It  must  be  recognized  that  such  simple  transfer,  while  commonly  understood  and  generally 
important,  will  not  support  all  applications  of  RAM.  Clause  18  defines  Implementation  Profiles  of  FTAM 
services  and  protocol  that  can  provide  other  specific  functions.  Those  other  functions  exploit  the  access 
and  management  capabilities  of  FTAM.  The  unconstrained  service  dass  (with  appropriately  chosen  functional 
units)  can  be  used  to  provide  the  functions  of  any  of  the  Implementation  Profiles.  Users  of  FTAM  must 
consider  carefully  what  functions  they  require.  They  must  examine  all  the  Implementation  Profiles  and  select 
according  to  their  needs. 

Implementations  conforming  to  these  Agreements  require  adherence  to  the  General  Agreements  in  clauses 
5  through  16  of  these  Agreements. 

Implementations  conforming  to  these  agreements  shall  implement  the  defect  report  solutions  contained  in: 

ISO  8571 -1/Cor.1:1 990 
ISO  8571 -2/Cor.1:1 990 
ISO  8571 -3/Cor.1:1 990 
ISO  8571 -4/Cor.1: 1990 

ISO  8571 -3/Cor.2: 1990 
ISO  8571 -4/Cor.2: 1990 

Editor's  Note  -  The  corrigenda  ISO  8571-3/Cor.2  and  ISO  8571-4/Cor.2  is  to  be  published.  Until  it  is 
available,  the  solutions  can  be  found  in  the  documents  ISO/IEC  JTC1/SC21  N  5234  and  ISO/IEC  JTC1/SC21 
N  5235. 


I  17.1    Interoperable  configurations 

I  Any  implementation  conforming  to  this  specification  must  be  able  to  act  in  at  least  one  of  the  following  role 

'  combinations: 

i 

j 

1.  initiator  and  receiver. 

2.  initiator  and  sender, 

3.  responder  and  sender, 

4.  responder  and  receiver. 

Minimal  implementations  of  combination  1  will  interoperate  with  minimal  implementations  of  combination  3. 
Minimal  implementations  of  combination  2  will  interoperate  with  mininral  implementations  of  combination  4. 
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Any  impiementations  of  roles  1  and  3  will  be  able  to  interoperate  at  the  intersection  of  their  capaMities 
(which  will  be  at  least  the  minimal  capabilities  described  in  17.3  to  17.8).  Any  implementations  of  roles  2 
and  4  will  be  able  to  interoperate  at  the  intersection  of  their  capabilities  (which  wW  be  at  least  the  minimal 
capabilities  described  in  17.3  to  17.8). 

These  role  combinations  and  this  interoperability  are  shown  in  table  5  below. 


Table  5  -  Interoperable  configuratlont. 


Inttiator 

Responder 

sender 

receiver 

serKler 

receiver 

1 

1  Initiator 

sender 

X 

receiver 

X 

Responder 

sender 

X 

receiver 

X 

17.2    Relationship  to  ISO  8571 -The  FTAM  Standard 

Any  implementation  in  conformance  to  ISO  8571  (as  defined  in  ISO  8571-4,  dause  22  (Confomiance)),  in 
addition  to  the  implementation  of  the  minimal  protocols  and  roles  enumerated  in  sut)claLiSM  17.3  to  17.8, 
is  considered  to  be  in  conformance  with  these  Agreements.  Any  implementation  violating  any  of  the 
conformance  statements  in  ISO  8571-4  is  considered  to  t>e  in  violation  of  tliese  Agreements. 


17.3    Requirements  for  document  type  support 

The  document  type  FTAM-3  shall  be  supported  for  purposes  of  transfer  and  storage.  The  detaHs  regarding 
support  for  FTAM-3  in  the  FTAM  dialogue  are  given  in  clause  10. 

Support  of  document  types  other  than  FTAM-3  is  not  required  for  conformant  implementations.  Support 
for  document  types  descrit>ed  in  these  Agreements  also  entails  support  for: 

the  semantics  given  in  their  description  and  further  qualified  in  clause  10 

the  preferred  transfer  syntax  "Basic  Encoding  of  a  single  ASN.1  type" 
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17.4  Initiators 

Every  implementation  of  an  FTAM  Initiator  shall  support: 

the  kemel  protocol  and  its  mandatory  parameters  with  minimum  ranges  [Minimum  required  ranges 
are  specified  in  17.8.], 

the  grouping  protocol  and  the  <  threshold  >  parameter  with  a  value  of  at  least  2  for  use  in  the  file 
transfer  class, 

at  least  one  of  the  read  or  write  protocols  [Specific  confonnance  for  reading  and  writing  is  defined 
In  17.6  and  17.7.], 

and  support  the  applicable  procedures  defined  In  ISO  8571-4  clauses  8.1  (FTAM  regime  establishment),  8.2 
(FTAM  regime  termination),  8.3  (File  selection),  8.4  (File  deselection),  8.9  (File  open),  8.10  (File  close),  8.1 1 
(Begin  group),  8.12  (End  group),  and  10  (File  general  actions).  To  support  the  above  protocols  and 
procedures  the  implementation  shall  always  support  the  kernel  functional  unit  and  additionally  shall  be  able 
to: 

request  the  grouping  and  at  least  one  of  the  read  or  write  functional  units, 
request  the  file  transfer  class  with  the  <  service  class  >  parameter, 

request  the  document  type  FTAM-3  using  the  <  document  type  name>  form  of  the  <  contents  type> 
parameter, 

request  the  <  FTAM  quality  of  service  >  parameter  with  value  0  and  accept  in  all  cases  the  returned 
value  0,  and 

request  a  <  communication  quality  of  service  >  consistent  with  the  transport  definition  in  these 
agreements. 

as  part  of  the  Filestore  initialization  procedures  in  ISO  8571-4  clause  8.1,  FTAM  regime  establishment. 

Initiators  must  be  able  to  operate  under  all  circumstances  if  the  above  minimum  values  are  successfully 
negotiated  and  returned  on  an  <F-INITIALIZE  response  >  PDU.  Initiators  must  be  able  to  operate  with  any 
downward  negotiation  of  requested  parameter  values  as  described  in  the  standard. 

Should  the  supporting  services  break  down,  such  that  FTAM  communication  is  impossible,  the  FTAM 
protocol  machine  shall  notify  the  user  with  an  <F-P-ABORT  indication >  and  <diagnostic>  value  with 
identifier  1011,  as  well  as  any  known  <  further  details  >. 

NOTE  -  Interworking  may  not  be  possible  t)etween  Initiators  not  supporting  attributes  of  the  Storage  Group 
and  Security  Group,  and  Responders  requiring  these  attributes  to  be  used. 
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17.5  Responders 

Every  implementation  of  an  FTAM  Responder  shall  support: 

the  kernel  protocol  and  its  mandatory  parameters  with  minimum  ranges  [Minimum  required  ranges 
are  specified  in  17.8.]. 

the  grouping  protocol  and  the  <  threshold  >  parameter  with  a  value  of  at  least  2  for  use  in  the  fie 
transfer  dass, 

at  least  one  of  the  read  or  write  protocols  [Specific  conformance  for  reading  and  writing  is  defined 
In  17.6  and  17.7], 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clauses  9.1  (FTAM  regime  establishment).  9.2 
(FTAM  regime  termination),  9.3  (File  selection).  9.4  (File  deselection).  9.9  (File  open).  9.10  (File  dose).  9.11 
(Begin  group),  9.12  (End  group),  and  10  (File  general  actions).  To  support  the  above  protocols  and 
procedures  the  implementation  shall  always  support  the  kernel  functional  unit  and  additionally  shall  be  able 

to: 

accept  requests  for  the  grouping  and  at  least  one  of  the  read  or  write  functional  units, 

accept  requests  for  the  file  transfer  dass  with  the  <  service  dass>  parameter. 

accept  the  document  type  FTAM-3  using  the  <  document  type  name>  form  of  the  <  contents  type> 
parameter, 

accept  requests  for  an  <FTAM  quality  of  service  >  parameter  with  any  value  but  may  respond  with 
the  value  0.  and 

accept  requests  for  a  <  communication  quality  of  service  >  consistent  with  the  transport  definitk}n 
in  these  agreements 

as  part  of  the  filestore  Initialization  procedures  in  ISO  8571-4  dause  9.1.  FTAM  regime  establishment. 

Responders  must  be  able  to  operate  under  ail  circumstances  if  the  above  minimum  values  are  requested 
on  an  <F-INITIAUZE  request >  PDU.  Responders  must  not  negotiate  upward  In  the  sense  described  in  the 
standard. 

Responders  must  complete  each  action  requested  and  supported  In  a  manner  consistent  with  its  descriptk)n 
in  ISO  8571  -2  dauses  10  (Actions  on  complete  files)  and  1 1  (Actions  for  file  access),  and  must  interpret  each 
supported  attribute  in  a  manner  consistent  with  its  definitkMi  in  ISO  8571-2  dause  12  (File  attributes). 

Under  circumstances  where  actions  cannot  be  carried  out  either  as  requested  or  consistently  with  ISO  8571- 
2  dause  10  (Actions  on  complete  files)  and  12  (Actions  for  fHe  access),  the  Responder  must  retum  at  least 
one  diagnostic  indicating: 

if  the  failure  was  due  to  either  a  protocol  or  Filestore  failure,  and  then: 

1)  precisely  which  action  failed. 
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2)  at  least  one  of  the  parameters  that  could  not  be  accommodated  with  the  diagnostic 
type  indicating  at  least  the  degree  of  failure,  as  given  by  the  action  and  state  result 
parameter,  or 

that  the  feiHure  was  due  to  unforeseen  system  shutdown. 

Should  the  supporting  services  brealc  down,  such  that  FTAM  communication  is  Impossible,  the  FTAM 
protocol  machine  sfiall  notify  the  user  with  an  <F-P-ABORT  indication >  and  <diagnostic>  with  identifier 
1011,  as  well  as  Inform  the  user  of  any  known  <furtfier  details>. 


17.6  Senders 

Every  implementation  of  an  FTAM  sender  shall  support  the  read  functional  unit  as  Responder  or  the  write 
functional  unit  as  Initiator,  and  support  the  applicable  procedures  defined  in  ISO  8571-4  clauses  11  (State 
of  the  bulk  data  transfer  activity).  12  (Bulk  data  transfer  protocol  data  units).  15  (Bulk  data  transfer  sending 
entity  actk>ns),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  sfiall  be  able  to  send  files  of  the  document  type  FTAM-3 
and  shall  be  able  to  send  them  as  user  data  in  PPDUs  in  blocks  of  up  to  7168  octets. 


17.6.1      Initiator  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  RAM  Initiator  shall  support: 
the  write  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 


and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clause  13  (Bulk  data  transfer  initiating  entity 
acttons). 

17.6.2     Responder  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  RAM  Responder  shall  support: 
the  read  functional  unit  arxl  protocol,  and 

for  the  document  type  RAM-3  the  following  bulk  data  transfer  specification  parameters: 


FADU  operation 


replace 


FADU  kientlty  first 


1)  FADU  kientlty 


first 


2)  Access  context 


UA 
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and  support  the  applicable  procedures,  defined  in  ISO  8571  -4  clause  1 4  (Bulk  data  transfer  responding  entity 
actions). 

17.7  Receivers 

Every  Implementation  of  an  FTAM  receiver  shall  support  the  read  functional  unit  as  Initiator  or  the  write 
functional  unit  as  Responder,  and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clauses  11 
(State  of  the  buli<  data  transfer  activity),  12  (Bull<  data  transfer  protocol  data  units),  16  (Bulk  data  transfer 
receiving  entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to  receive  files  of  the  document  type  FTAM-3 
and  shall  be  able  to  receive  them  as  user  data  in  PPDUs  In  blocks  of  at  least  7168  octets. 

17.7.1  Initiator  Receivers 

Every  implementation  of  an  FTAM  receiver  which  Is  also  an  FTAM  Initiator  shall  support: 
the  read  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

1)  FADU  identity  first 

2)  Access  context  UA 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clause  13  (Bulk  data  transfer  initiating  entity 
actions). 

17.7.2  Responder  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  Responder  shall  support: 
the  write  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

1)  FADU  operation  replace 

2)  FADU  Identity  first 

and  support  the  applicat>le  procedures,  defined  in  ISO  8571  -4  clause  14  (Bulk  data  transfer  responding  entity 
actions). 
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17.8    Minimum  ranges 

Any  implementation  off  any  confomiant  FTAM  configuration  shall  be  abie  to  receive  arxJ  meaningfully  process 
al  mandatory  parameters  for  ail  functional  units  supported  as  well  as  the  <diagnostic>  parameter  within 
at  least  the  minimum  ranges  of  values  given  in  tabUe  6.  A  conforming  implementation  may  support  a  wider 
range  of  values  for  any  parameter. 


Table  6  -  Required  minimal  parameter  support 


Parameter 

Minimum  Range 

general 

diagnostic 

Values  as  specified  in  ISO  8571-3  annex  A  (Diagnostic 
parameter  values)  tables  44,  45  and  46  which 
oorrespoTKi  directly  to  niarKlatory  parameters. 

action  result 

All  values 

state  result 

All  values 

F-INHIAUZE 

functional  units* 

'read'  (for  initiator/receivers  and  responder/senders) 

and  'grouping' 

or 

'write'  (for  initiator/senders  and  responder/receivers) 
and  'grouping' 

presentation  context 
management^ 

'False' 

alt  others 

As  specified  in  17.4  and  17.5  above 

F-SEI^CT 

attributes 

Only  <  filename  >  is  used  with  a  minimum  supportable 
length  of  8  characters.  Any  other  attribute  supported 
for  other  services  must  have  minimum  supported 
lengths  as  in  ISO  8571-2  clause  15  (Minimum  attribute 
ranges),  table  2. 

requested  access 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

F-CREATE 

override 

For  Responders.  the  values  'create-failure',  'select-old- 
file'  and  'delete-and-create-with-new-attributes'  are 
supported.  The  value  'delete-and-create-with-old- 
attributes'  is  optionally  supported.  All  values  are 
optional  for  Initiators. 
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Tabig  6  -  Rctqulred  minimal  parameter  support,  (concluded) 


Parain«l«r 

Minimum  Rang*  | 

F-OPEN 

DrocAfifiinn  mod  a 

'read'  for  Initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/recelvers 

contonts  typ6 

'FTAM-3' 

F-READ 

FADU  identity 

•firsf 

access  context 

m 

F-WRITE 

FADU  operation 

'read'  for  Initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

FADU  identity 

'firsf  1 

F-BEGIN-GROUP 

threshold* 

For  file  transfer  (a  minimal  required  function)  2  \ 

For  any  other  supported  parameters,  minimum  ranges  are  taken  from  the  minimum  ranges  for  the  attribute 
corresponding  to  each  as  in  ISO  8571-2  table  4. 

NOTES 

1  The  parameters,  functional  units,  and  presentation  context  management  are  not  ordered,  so  'minimum 
value'  cannot  be  formally  defined.  The  above  values  are  those  required  for  confomiance  to  these  Agreements 
but  no  value  conformant  to  ISO  8571  for  use  in  other  applications  is  regarded  to  be  in  violation  of  these 
Agreements. 

2  Other  functional  units  (and  service  classes)  for  defined  implementations  may  also  be  valid  provided  that  they 
are  implemented  in  accordance  with  these  Agreements,  specifically  subclause  1 7.8. 

3  Every  implementation  must  support  the  <  threshold  >  value  2  to  provide  the  basic  required  function  of  file 
transfer;  any  other  value  in  other  applications  is  acceptable. 
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17.9  Range  of  values  for  INTEGER  type  parameters 

The  general  range  for  parameters  of  type  INTEGER  to  the  FTAM  PCI  Is  as  specified  In  the  UNIVERSAL 
ASN.1  ENCX)DING  RULES  clause  of  the  Upper  Layers  part. 

The  paranieters 

FTAM  Attributes 

filesize 

future-filesize 

FADU-ldentlty 

fadu-number 

may  be  eruxxled  so  that  the  length  of  its  contents  octets  is  no  more  than  eight  octets. 
In  the  case  of  receiving  more  than  4  contents  octets,  the  receiver  may  reject  the  corresponding  FTAM  PDU. 
NOTE  •  To  guarantee  inter\worl<ing,  encoding  should  be  restricted  to  the  range  -2^^  to  2^^-1. 

17.10  Use  of  lower  layer  services 

Support  for  the  Presentation  Context  Management  functional  unit  is  not  required. 

Impiementattons  will  support  the  Session,  Presentation,  and  ACSE  requirements  as  stated  in  part  5  of  this 
document. 

NOTE  -  Implementation  of  the  Session  Resychronize  and  the  Minor  Synchronize  functional  units  is  highly 
recommended,  since  the  F-CANCEL  service  may  be  less  effective  when  mapped  to  S-DATA. 
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18  Implementation  Profiles 

This  clause  defines  Implementation  Profiles  for  the  specific  functions  of: 

File  Transfer 

File  Access 

File  Management 
Those  definitions  are  expressed  in  terms  of: 

Document  Types 

Attributes 

Service  Classes  (both  sen/ice  elements  and  their  parameters). 

This  by  no  means  defines  all  possible  Implementation  Profiles.  The  following  Implementation  Profiles  are 
defined: 

T1  :  Simple  File  Transfer 
T2  :  Positional  File  Transfer 
T3  :  Full  File  Transfer 
A1  :  Simple  File  Access 
A2  :  Full  File  Access 
Ml  :  Management. 

Implementation  Agreements  have  been  reached  for  the  following  service  classes. 
File  Transfer 
File  Access 
File  Management 
Unconstrained 

File  Transfer  and  Management 

NOTE  -  Any  given  implementation  may  support  more  than  one  service  class. 
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Support  of  an  implementation  Profile  requires  adherence  to: 

corresponding  definition  in  8571-3  clause  8  and  any  related  procedures  in  8571-4  clause  8-17, 
requirements  given  In  clauses  5-18  of  these  Agreements,  and 
requirements  for  parameter  and  attribute  support  as  defined  in  17.8. 

18.1  General  requirements  for  the  defined  Impiementation  Profiles 

Implementations  will  be  able  to  act  either  as  initiator  or  Responder  or  both. 

Implementations  must  support  diagnostics  as  described  In  clause  13  of  these  Agreements. 

Implementations  that  support  the  file  access  service  class  will  support  access  to  sequential  flies.  Support 
of  sequential  files  entails  hierarchy  of  depth  and  arc  length  equal  to  1.  Other  hierarchy  depth  and  arc 
lengths  are  not  precluded  by  these  agreements. 

18.2  (deleted) 

18.3  Document  type  requirements  for  the  defined  Implementation 
Profiles 

implementations  conformant  to  implementation  Profiles  defined  in  table  7  will  support  the  following 
document  types  with  the  caveats  and  procedures  given. 

FTAM-1 

FTAM-2 

FTAM-3 

NBS-6 

NBS-7 

NBS-8 

NBS-9 

NOTES 

1  Support  of  this  document  type  entails  ttie  naming  of  FADUs  by  their  position  in  preorder  traversal. 

2  Caveat  Other  methods  of  naming  FADUs  depend  on  the  system,  application,  and  specific  file,  and  as  such 
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are  not  described  here. 

3  Those  document  types  are  defined  in  annex  A  and  clause  10  of  these  Agreements,  and  in  ISO  8571-2. 

Support  for  any  document  type  requires  the  ability  to  transfer  and  store  tlie  abstract  syntax  given  in  its 
definition.  These  Agreements  do  not  specify  techniques  or  formats  for  storage. 

NOTE  -  Specific  abstract  syntaxes  for  the  parameterized  document  types  NBS-6,7,8  are  not  specified  in  these 
Agreements. 

Any  document  type  supported  must  be  identifiable  by  its  document  type  name  as  given  in  ISO  8571-2  and 
in  annex  A  of  these  Agreements  and,  where  defined,  the  parameterization  scheme  given  in  clause  10  of 
these  Agreements. 

For  conformance  to  NBS-9  a  Responder  Is  only  required  to  return  the  <  filename  >  attribute,  subject  to  iocai 
security  and  access  control.  All  other  requested  attributes  need  not  be  returned. 

Systems  supporting  the  NBS-9  document  type  shall  mal<e  availat}le  an  NBS-9  document  called  "DIRUS." 
This  document  can  be  used  to  obtain  a  listing  of  files  and  their  associated  attributes  from  a  remote  Filestore. 

Creation  and  deletion  of  NBS-9  files  are  outside  the  scope  of  these  Agreements. 

File  security  issues  related  to  NBS-9  are  subject  to  the  security  agreements  outlined  in  clause  16. 


1 8.4    Parameters  for  the  defined  Implementation  Profiles 

implementations  will  support  the  <  contents  type  list>  parameter  on  the  <F-INITIAUZE>  service  element. 
The  initiating  service  must  supply  a  value  for  this  parameter. 

Implementations  will  support  the  <diagnostic>  parameter  as  stated  in  clause  13  of  these  Agreements. 

The  <  initiator  identity >  parameter  is  supported.  Use  must  be  consistent  with  clause  16  of  these 
Agreements. 

Implementations  are  not  precluded  from  using  other  parameters  for  security  and /or  accounting.  Responders 
must  state  the  syntax  and  the  semantics  applying  to  <  account  >  and  <  charging  >  parameters.  The 
Responder's  minimum  implementation  is  to  accept  but  Ignore  the  <  account  >. 


1 8.5    Parameter  ranges  for  the  defined  Implementation  Profiles 

Parameter  ranges  for  Implementations  Profiles  are  as  stated  for  primitive  data  types  in  clause  10  of  these 
Agreements. 
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18.6    File  attribute  support  for  Implementations 

Implementations  of  the  Implementation  Profiles  will  support  file  attributes  or  attribute  groups  in  the  foiiowing 


a)  mandatory  -  This  feature  is  mandatory  in  the  ISO  8571-2  standard  and  shall  therefore  be 
implemented  by  ail  implementations  claiming  conformance  to  these  Agreements; 

b)  supported  -  This  feature  shall  be  implemented  by  all  implementations  claiming  conformance  to 
these  Agreements  (for  attributes,  this  implies  tliat  at  least  the  minimum  range  of  attribute  values,  as 
defined  in  ISO  8571-2  clause  15,  shall  be  supported).  Conformant  implementations  shall  also  be 
able  to  Interwork  with  other  implementations  that  do  not  support  this  feature  by  negotiating  out  the 
corresponding  features; 

c)  optionally  supported  -  implementations  claiming  conformance  to  these  Agreements  may  or  may 
not  Implement  this  feature  (for  attributes,  this  implies  that  at  least  either  the  minimum  range  Of 
attribute  values,  as  defined  In  ISO  8571-2  clause  15,  shall  be  supported  or  that  the  "no  value 
available"  result  shall  t>e  supplied),  if  an  attribute  group  with  a  support  level  of  "optionally 
supported"  Is  chosen  to  t>e  supported,  then  all  the  attributes  of  this  group  that  are  classified  as 
"mandatory"  or  "supported"  shall  be  supported; 

d)  not  supported  -  This  feature  is  outside  the  scope  of  these  Agreements. 


ways: 


I 
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ItoriMl  Group 
Filename 
Permitted  Actions 
Contents  Type 

Storage  Group 

Storage  Account 

Date  and  Tinrte  of  Creation 

Date  and  Time  of  Last  Modification 

Date  and  Time  of  Last  Read  Access 

Date  and  Time  of  Last  Attribute  Modification 

Identity  of  Creator 

Identity  of  Last  Modifier 

Identity  of  Last  Reader 

Identity  of  Last  Attribute  Modifier 

File  Availability 

Filesize 

Future  Filesize 

Security  Group 

Access  Control 
Legal  Qualifications 

Private  Group 


mandatory 
mandatory 
mandatory 
mandatory 

optionally  supported 
optionally  supported 
optionaJly  supported 
optionally  supported 
optionally  supported 
optiorudly  supported 
optionally  supported 
optiorially  supported 
optionally  supported 
optionally  supported 
supported 
supported 

optionally  supported 

optionally  supported 
supported 

optionally  supported 
not  supported 
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Table  7  -  Implementation  profiie  support  requirements 


PiinoflAnol  Units 

Service  Classes   (see  note  8) 

T 

M 

A 

TM 

Uncon- 
strained 

Kernel 

11. 12, 13 

M1 

A1,  A2 

see 
note  4 

see 
note  5 

Read  (see  note  3) 

11.12,13 

A1,  A2 

Write  (see  note  3) 

11,12,13 

A1.  A2 

Limited  File  Management 

see  note  6 

Ml 

see  note  6 

Enhanced  File 
Management 

Ml 

Grouping 

T1.T2, 13 

Ml 

File  Access 

A1,  A2 

Document  Types 

FTAM-1 

11, 12, 13 

[Ml] 

A1,  A2 

FrAM-2 

12,  T3 

[Ml] 

A1.  A2 

FTAM-3 

11,  T2, 13 

[Ml] 

A1.  A2 

NBS-6 

F2].  13 

[Ml] 

[A1].  A2 

NBS-7 

[T2].  13 

[Ml] 

[A1].  A2 

NBS-8 

13 

[Ml] 

A2 

NBS-9 

[Tl],  [12],  [13] 

[Ml] 

I  NOTES 

I  to  18.3  and  table  7 

!  1  The  Management  Implementation  Profile  is  only  to  be  implemented  in  conjunction  with  one  of  the  Transfer 

I  or  Access  Profiles. 

\  2  Profile  T2  is  subset  of  T3.  A1  and  Tl  are  subsets  of  A2  and  T2.  respectively. 

3  Profiles  Tl,  T2.  and  T3  require  the  support  of  read  and/or  write  functional  units. 

4  Support  of  the  <  File  Transfer  and  Management>  service  class  is  optional.  The  mles  for  including  it  in  a 
request  and  for  the  response  to  it  are  as  given  in  ISO  8571-3,  clause  10.1.  Any  implementation  including  TM 
in  the  request  must  be  prepared  for  the  possibility  that  it  might  be  removed  from  the  response. 

5  The  support  of  the  <  Unconstrained >  service  class  is  outside  the  scope  of  these  Implementation  Profiles. 

6  Limited  File  Management  is  not  required  for  the  T-  and  A-  Implementation  Profiles,  but  very  often  it  will  be 
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a  user  request  to  have  limited  file  management  functionality  available  together  with  file  transfer  and  file  access 
functions.  So  Limited  File  Management  may  be  added  as  an  option  to  ttie  T-  and  A-  Implementation  Profiles. 

7  [  1  in  table  7  specifies  that  the  document  type  is  optional  for  the  respective  Implementation  Profile.  For  Ml 
the  support  level  depends  on  the  T-  or  A-  Implenwntation  Profile,  in  conjunction  with  which  Ml  is  implemented. 

8  The  Implementation  Profiles  specify  functionality  which  includes  the  requirements  for  conformant 
implementations  as  specified  in  clause  1 7.  This  is  a  general  basic  requirement  and  is  not  also  reflected  in  table 
7. 

19  PROVISION  OF  SPECIFIC  FUNCTION 

II  ■ 

19.1  Implementation  Prof  lie  T1 :  Simple  File  Transfer 

Implementation  Profile  T1  provides  the  function  of  transferring  entire  files  at  the  external  file  service  level  for 
files  with  an  unstructured  constraint  set.  This  includes  support  of  the  document  types: 

,        FTAM-1  "ISO  FTAM  unstmctured  text" 

FTAM-3  "ISO  FTAM  unstructured  t)inary" 

NBS-9  'NBS-9  file  directory  file'  (optional) 

This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  at>ility  to 

read  a  complete  file,  and/or 

write  (replace,  extend)  to  a  file. 

19.2  Implementation  Profile  T2:  Positional  File  Transfer 

Implementation  Profile  T2  provides  the  function  of  transferring  files  at  the  external  file  service  level  for  files 
with  an  unstructured  or  flat  constraint  set.  This  includes  support  of  the  document  types: 

FTAM-1  "ISO  FTAM  unstructured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3  "ISO  FTAM  unstructured  t>inary' 

NBS-6  "NBS-6  FTAM  sequential  file"  (optional) 

NBS-7  "NBS-7  FTAM  random  access  file"  (optional) 

NBS-9  "NBS-9  file  directory  file"  (optional) 
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This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is.  the  at)lity  to 
read  a  complete  file  or  a  single  FADU  which  is  identified  by  position,  and/or 
write  (replace,  wt&nd,  insert  depending  on  constraint  set  and  document  type)  to  a  fie  or  an  FADU. 
This  Implementation  Profile  is  upwardly  compatibie  to  T1  for  the  transfer  of  unstructured  flies. 

19.3  Implementation  Profile  T3:  Full  File  Transfer 

Implementation  Profile  T3  provides  the  function  of  transferring  files  at  the  external  file  sen/ice  level  for  fites 
with  an  unstructured,  flat  or  general  hierarchical  constraint  set  This  includes  support  of  the  document 
types: 

FTAM-1  "ISO  FTAM  unstructured  texT 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3         "ISO  FTAM  unstnjctured  binary" 
NBS-6  "NBS-6  FTAM  sequential  flie" 
NBS-7  'NBS-7  FTAM  random  access  file" 
NBS-8  "NBS-8  FTAM  indexed  file" 
NBS-9  "NBS-9  file  directory  file"  (optional) 
This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is.  the  ability  to 

read  a  complete  file  or  a  single  FADU  which  is  identified  by  Icey  or  by  position,  and/or 
write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file  or  an  FADU. 
This  Implementation  Profile  is  upwardly  compatible  to  T1  for  the  transfer  of  unstructured  files. 

19.4  Implementation  Profile  A1:  Simple  File  Access 

I  Implementation  Profile  A1  provides  the  function  of  transfer  of  and  access  to  files  with  unstructured  or  flat 
^   constraint  sets  at  the  external  file  service  level.  This  includes  support  of  the  document  types: 

I  FTAM-1  "ISO  FTAM  unstmctured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

i 

FTAM-3  "ISO  FTAM  unstmctured  binary" 
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NBS-6  -NBS-6  FTAM  sequential  ffle'  (optional) 
NBS-7  'NBS-7  FTAM  random  access  file'  (optional) 
This  Implenientation  Profile  supports  file  transfer  and  file  access,  that  is  the  at>ility  to 
read  a  complete  fHe  or  FADUs  which  are  Identified  by  position, 

write  (replace,  extend,  insert  deperxiing  on  constraint  s^  arxi  document  type)  to  a  file  or  an  FAOU, 
locate  and  erase  within  fHes. 

19.5  Implementation  Profile  A2:  Full  File  Access 

implementation  Profile  A2  provides  the  function  of  transfer  of  and  access  to  files  with  unstructured  or  flat 
constraint  sets  at  the  external  file  service  level.  This  includes  support  of  the  document  types: 

FTAM-1  "ISO  RAM  unstmctured  texr 

FTAM-2  'ISO  FTAM  sequential  text" 

RAM-3  'ISO  FTAM  unstmctured  binary" 

NBS-6  'NBS-6  FTAM  sequenty  file" 

NBS-7  "NBS-7  FTAM  random  access  file" 

NBS-8  "NBS-8  FTAM  indexed  fUe" 

This  Implementation  Profile  supports  file  transfer  and  file  access,  that  Is,  the  ability  to 

read  from  a  complete  file,  or  from  a  series  of  FADUs  which  are  identified  by  key  or  by  position. 

write  (replace,  extend,  insert  depending  on  constraint  set  arxi  document  type)  to  a  file  or  an  FADU, 

locate  and  erase  within  files. 

19.6  Implementation  Profile  Ml :  Management 

Implementation  Profile  M1  provides  the  function  for  an  Initiator  to  manage  the  files  within  the  Virtual  Filestore, 
to  which  access  Is  provided  by  the  Responder.  Management  includes  the  services  of: 

creating  a  file 

deleting  a  file 

reading  attributes  of  a  file 
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20  Harmonization 

The  Implementation  Profiles  for  FHe  Transfer.  Fie  Access  and  Management  correspond  to  the  Profiles  of 
SPAG  (Standards  Promotion  and  Application  Group)  in  Europe,  so  that  intentvoriclng  will  be  possitile.  Those 
Profiles  are  descrit)ed  in  the  "Guide  to  the  Use  of  Standards"  (GUS):  they  are  the  tresis  for  the  Functional 
Standards  as  defined  by  CEN/CENEL£C  (Comite  Europeenne  de  Nonmaiization). 


Table  8  -  Implementation  proflies  (OIW)  and  profiles  (SPAG/CEN-CLC) 


1      lmpl«m«ntallofi  Profile 

SPAG  /  CEN^ENELEC  | 

T, 

A/111  1 

T2 

A/112  1 

T3 

A/113  1 

A1 

A/122  1 

1  A2 

A/123  1 

1  M1 

A/13  1 
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Annex  A  (normative)  

FTAM  Document  Types 

EdHor's  Note  -  The  objects  defined  in  A.5  through  A.8,  B^,  C.3  and  C.4  will  be  removed  from  this  document 
after  ISO/IEC  ISP  10607-2  and  ISO/IEC  ISP  10e07-2/Amd.1  are  published.  During  the  period  between 
publishing  the  ISP  and  removal  of  the  definitions  from  this  document,  the  definitions  in  tt>e  ISP  will  take 
precedence  over  this  document.  When  the  object  definitions  are  removed,  clauses  A.1  through  A.4,  B.I,  C.I 
and  C.2  will  be  changed  to  point  to  the  ISP. 

The  objects  defined  in  A.5  througli  A.8,  B.2,  C.3  and  C.4  will  be  removed  from  this  document  after  ISO/IEC 
ISP  10607-2  and  ISO/IEC  ISP  10607-2/Amd.1  are  published.  During  the  period  betweem  publishing  the  ISP 
and  removal  of  the  definitions  from  this  document,  the  definitions  in  the  ISP  will  take  preceedence  over  this 
document.  When  the  object  definitions  are  removed,  clauses  A.1  through  A.4,  B.I,  C.I  and  C.2  will  be 
changed  to  point  to  the  ISP. 

A.1     NBS-6  Sequential  file  document  type 


This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  document-type(5)  sequential(6)} 

was  withdrawn  on  March  16.  1990.  It  was  replaced  with  the  object  NBS-6  Sequential  file  document  type 
with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamslg(5)  document-type(5)  sequential(6)} 
defined  in  part  9,  A.5. 


A.2     NBS-7  Random  access  file 

i  This  object  with  Object  Identifier 

I  {Iso  Identified-organization  icd(9999)  organization-code(l)  document-type(5)  random-file(7)} 

^  was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS-7  Random  access  file  docunr>ent 
I  type  with  the  Object  Identifier 

jl  {Iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  random-access(7)} 
I  defined  in  part  9,  A.6. 
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A.3     NBS-8  Indexed  sequential  file 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  document-type(5)  indexed-file(8)} 

was  withdrawn  on  March  16. 1990.  It  was  replaced  with  the  object  NBS-8  Indexed  sequential  file  document 
type  with  the  Ot)ject  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  docun:)ent-type(5)  indexed-file(8)} 
defined  in  part  9.  A.7. 

A.4     NBS-9  File  directory  file 

This  object  with  Object  Identifier 

{iso  identified-organization  led (9999)  organization-code(l)  document-type(5)  file  directory(9)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  NBS-9  File  directory  file  document  type 
with  the  Object  Identifier 

{Iso  identified-organization  olw(14)  ftamslg(5)  document-type(5)  file<Jirectory(9)} 
defined  in  part  9.  A.8. 


A.5     NBS-6  Sequential  file  document  type 


A.5.1 


Entry  Number:  NBS-6 


A.5.2 


Information  objects 
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Table  9  -  Information  objects  In  NBS-6 


doeuiiMnt  typ«  name 


{iso  identified-organization  oiw(14)  ftam8ig(5)  document-type(5)  I 
8equential(6)}  " 
'NBS-6  FTAM  sequential  file' 


•bslracl  syntax  names: 

a)  name  for  asnamel 


b)  name  for  asname2 


{iso  identified-organization  oiw(14) 
ftamsig(5)  ab8tract-syntax(2)  nb8-as1(1)} 
'NBS  abstract  syntax  AS1' 

{iso  standard  8571  abstract-syntax(2)  ftanvfadu(2)} 
■fTAM  FADU' 


transfer  syntax  names: 


{joint-iso-cdtt  asn1(1)  ba8ic-encoding(1)} 
'Basic  Encoding  of  a  single  ASN.1  type' 


parameter  syntax: 

PARAMETERS  ::=  SEQUENCE  OF  CHOICE  {ParameterO.  Parameterl,  Parameter2} 
ParameteiO  ::»  [0]  INTEGER  {univer-time  (23), 

gen-time  (24), 

boolean  (1), 

null  (5)  } 

Parameterl  ::=  [1]  SEQUENCE  { 

universal-dass-number-l  INTEGER  {  int  (2), 

bit  (3), 
ia5  (22). 
graphic  (25), 
general  (27), 
octet  (4)}, 

string-length  INTEGER  } 
Parameter2  ::=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)>, 
length-1  INTEGER, 
 length-2     INTEGER  } 


file  model 


{iso  standard  8571  file-model(3)  hierarchical(l)} 
'FTAM  hierarchical  file  model' 


constraint  set 


{iso  standard  8571  constraint-set(4)  sequential-flat(2)} 
'FTAM  sequential  flat  constraint  sef 


file  corrtents: 


Datatypel  ::  =  PrimType  -  NBS-AS1 
Datatype2::=  Node-Descriptor-Data-Element 
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A.5.3      Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
NOTE  ~  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 

A.5.4  References 

ISO  8571 ,  Information  Processing  Systems  -  Open  Systems  Interconnection  •  File  Transfer,  Access  ano 
Management 


This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  In  ISO 
8571-1. 


A.5.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


A.5.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  zero  or 
one  data  unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  is 
significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  sequential  fiat  constraint  set  (see  table  9)  These  definitions  appear  in  ISO  8571-2.  As  additional 
constraints  FADU  identity  will  be  limited  to  "begin,"  "end,"  "first"  and  "next". 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is  given  by  the  parameters.  Each  data  element 
is  a  data  type  from  the  set  of  primitive  data  types  defined  in  the  annex  0.3  of  this  document.  Each  data 
unit  contains  the  same  data  element  types  in  the  same  order  as  all  other  data  units.  These  types  are 
determined  by  the  parameters  0  through  2. 

For  datatype  1 ,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets  for  the 
INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string-length  < 
indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding.  ' 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 


A.5.5 


Definitions 
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A.5.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchicaliy  structured  file  as  defined  in  the  ASN.1 
module  iS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  at>stract  syntactic 
structure  of  NBS-ASI  as  defined  by  the  parameters. 


A.5.9      Definition  of  transfer 


A.5.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  9,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-ASI 
definition;  or 

b)  Datatype2  defined  in  table  9,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU. 


A.5.9.2       Presentation  data  values 

The  document  is  transfen-ed  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel."  carrying  one  of  the  data  elements  from  the 
document.  Ail  values  are  transmitted  in  the  same  (but  any )  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
estat>iished  to  support  the  abstract  syntax  name  "asname2." 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  t>e  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  mai<es  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 


Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  cany  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 
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A.5.9.3 


Sequence  of  presentation  data  values 


The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 
structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571-2. 


A.5.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  9  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.5.11     ASE  specific  specifications  for  FTAM 


A.5.11.1       Structural  Simplification 

This  structural  simplification  loses  information. 

The  document  type  NBS-6  may  be  simplified  to  the  document  type  FTAM-3  (allowed  ortly  when  reading  the 
file).  The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 


A.5.11. 2      Access  context  selection 

A  document  of  type  NBS-6  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  sequential 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.5.11. 3      The  INSERT  operation 

When  the  <  INSERT  >  operation  is  applied  at  the  erxi  of  fUe,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-6  document  with  the  same  parameter  values  in 
access  context  FA. 


A.6 


NBS-7  Random  access  file 
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Table  10  ~  Information  objects  in  NBS-7 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(S)  document-type(5)  E 
rarKlom-file(7)}  | 
'NBS-7  FTAM  random  access  file*  | 

abetracft  ayntax  names: 

a)  name  for  asnamel 

b)  name  for  a8name2 

{iso  identified-organization  oiw(14)  ftam8ig(5)  ab8tract-syntax(2)  1 
nbs-as1(1)} 

'NBS  abstract  syntax  AS1' 

{iso  standard  8571  ab8tract-8yntax(2)  ftam-  fedu(2)} 

•FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-cdtt  asn1(1)  basic-encoding(l)} 
'Basic  Encoding  of  a  single  ASN.1  type' 

parameter  syrrtax: 

PARAMETERS  ::=  SEQUENCE  OF  CHOICE  {ParameterO.  Parameterl,  Parameters} 
ParameterO  ::  =  [0]  INTEGER  {univer-time  (23), 

gen-time  (24), 

txx}lean  (1), 

null  (5)  } 

Parameterl  ::=  [1]  SEQUENCE  { 

universal-class-number-1  INTEGER  {  int  (2), 

bit  (3), 
ia5  (22). 
graphic  (25), 
general  (27), 
octet  (4)}. 

string-length  INTEGER  } 
Param©ter2       [2]  SEQUENCE  { 

private-ciass-number  INTEGER  {float  (0)}, 
length-1  INTEGER, 
length-2     INTEGER  } 


file  model 


{iso  standard  8571  file-model(3)  hierarchical(l)} 
'FTAM  hierarchical  file  model' 


constraint  set 


{iso  identified-organization  oiw(14)  1tamsig(5)  constraint-set(4) 

nbs  ordered-flat(l)} 

*NBS  ordered  flat  constraint  sef 


file  contents: 


Oatatypel 

Datatype2 


:  =  PrimType  -  NBS-AS1 

:  =  CHOICE    {  Node-Descriptor-Data-Element, 
Enter-Subtree-Data-Element  } 
Exit-Sutnree-Data-Element  } 
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A.6.3      Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.6.4  References 

ISO  8571.  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer.  Access  and 
Management 


A.6.5  Definitions 

This  definition  nfial<es  use  of  the  temis  data  element,  data  unit  and  file  access  data  unit  as  defined  In  ISO 
8571-1. 


A.6.6  Abbreviations 

FTAM  FHe  Transfer,  Access  and  Management 


A.6.7      Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  zero  or 
one  data  unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  Is 
significant. 

The  document  structure  tal<es  any  of  the  fonns  allowed  by  the  RAM  hierarchical  file  model  as  constrained 
by  the  NBS-ordered-flat  constraint  set  (see  table  10).  These  definitions  appear  in  annex  B.2  of  this 
document. 

For  a  specific  file  the  number  of  data  elements  In  a  data  unit  Is  given  by  the  parameters.  Each  data  element 
is  a  data  type  from  the  set  of  primitive  data  types  defined  in  the  annex  0.3  of  this  document.  Each  data 
unit  contains  the  same  data  element  types  In  the  same  order  as  all  other  data  units.  These  types  are 


ij  For  datatype  1.  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  In  octets  for  the 
|j  llslTEGER.  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string-length 

Indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  Including  any  escape 

sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  fomi,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  iength-1  and  length-2  values  are  in-elevant  for  the  other  choices  of  floating  point 
numbers. 


j  determined  by  the  parameters  0  through  2. 
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A.6.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  fie  as  defined  in  the  ASN.1 
module  IS08571-FADU  in  ISO  8571.  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic  I 
structure  of  NBS-ASI  as  defined  by  the  parameters. 

A.6.9      Definition  of  transfer 

j 

Aa6.9.1        Datatype  definitions  | 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  10,  where  the  PrimType  in  the  datatype  Is  given  by  the  NBS-ASI 
definition; 

b)  Datatype2  defined  in  table  10.  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU. 


A.6.9.2       Presentation  data  values 


The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel."  canying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  In  the  same  (but  any )  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"; 

b)  a  value  of  "Datatype2.'  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2." 

NOTES 

1  Specific  carrier  Standards  may  impose  ackJitiorud  constraints  on  the  presam  ^ 
the  above  permits  a  choice.  j 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2.  or  starts  with  a  Datatype2  | 
transmission.  i 

1 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  tx)undaries  between  j 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 


semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 
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A.6.9.3       Sequence  of  presentation  data  values 


The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  Is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 
structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571-2. 


A.6.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  mies  named 
in  table  10  for  all  presentation  data  values  transfen-ed.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.6.11     ASE  specific  specifications  for  FTAM 


A.6.11.1       Structural  simplification 

This  structural  simplification  loses  information. 

The  document  type  NBS-7  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading  the 
fNe)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  Is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  In  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-7  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading  ttie 
file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  <  contents  type> 
parameter  on  the  <F-OPEN  request  >. 


A.6.11. 2      Access  context  selection 

A  document  of  type  NBS-7  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  NBS  ordered 
flat  constraint  set.  The  presentation  data  units  transfen'ed  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A6.1 1 .3      The  INSERT  operation 

When  the  <  INSERT >  operation  is  applied  at  the  end  of  file,  the  transfen-ed  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-7  document  with  the  same  parameter  values  in 
access  context  FA. 
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A.7.1 

A.7.2 


Entry  Number:  NBS-8 

Information  Objects 

Table  11  -  Information  objects  in  NBS-8 


docurvMnt  typ*  nam« 

{iso  identified-organlzation  oiw(14)  ftamsig(5)  document-type(5) 

indexed-file(8)} 

'NBS-8  FTAM  indexed  file' 

•bstrsct  syntax  names: 

a)  name  for  asnamel 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract  syntax(2) 
nbs-as1(1)} 

"NBS  abstract  syntax  AS1" 

b)  name  for  a8name2 

{iso  standard  8571  abstract-syntax(2)  ftam-  fadu(2)} 
■FTAM  FADU" 

transfer  ayntax  namea: 

{joint-iso-cdtt  asn1(1)  basic-encoding(l)} 
'Basic  Encoding  of  a  single  ASN.1  type' 

1  parameter  syrrtax: 

1    PARAMETERS  ::=  SEQUENCE 

{DataTypes,  KeyType,  KeyPosition} 

1    DataTypes  ::=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 

1    KeyType         CHOICE  {ParameterO,  Parameterl,  Parameter2} 

1                   -  ParameterO,  Parameterl,  Parameters,  as  defined  for  the 

1                   -  document  types  NBS-6,  NBS-7 

1    KeyPosition::-  INTEGER 

fils  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
'FTAM  hierarchical  file  model' 

0  constrsint  set 

{iso  standard  8571  constraint-set(4)  ordered-flat(3)  } 
'FTAM  ordered  flat  constraint  sef 

D  file  contents: 

1                Oatatypel  ::=  PrimType 

-  NBS-AS1 

Datatypes  CHOICE 

{  Node-Descriptor-Data-Element, 
Enter-Subtree-Data-Element, 
Exit-Subtree-Data-Eiement  } 

Datatypes  ::  =  Primtype  • 

-  as  defined  by  the  NBS  abstract  syntax  AS1 
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A.7.3      Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  using  FTAI^. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.7.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management 


A.7.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


A.7.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


A.7.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  one  data 
unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  FTAM  ordered  flat  constraint  set  (see  table  11).  These  definitions  appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of  the  ordered  flat  constraint  set: 

The  FADU  identities  "first,"  "last,"  and  "node  number"  are  not  required  for  conformant 
implementations 

The  Wentitles  "next"  and  "previous"  are  allowed  for  ail  FADUs 

Each  data  element  Is  a  data  type  from  the  set  of  primitive  data  types  defined  in  annex  0.3  of  this  document. 
Each  data  unit  contains  the  same  data  element  types  In  the  same  order  as  all  other  data  units.  These  types 
and  their  respective  maximum  lengths  are  defined  by  the  <DataTypes>  parameter. 

For  Datatypel  and  Datatypes,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets 
for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string- 
length  indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 
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For  floating  point  numbers,  finite  form,  lengtli-1  and  length-2  specify  tlie  iengtli  in  bits  of  mantis  and  [ 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 
numbers. 

Each  data  unit  in  the  file  has  a  key  associated  with  It,  which  Is  the  user-coded  form  of  Node-Name.  The  key 
of  each  data  unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a  single  data 
element  from  the  set  of  primitive  data  types  defined  in  annex  C.3. 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType>  parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which  an  implementation  must  accept  as 
a  key  value  are  given  in  the  following  table  12. 


Table  12  -  Datatypes  for  keys 


Key  Type 

Minimum  Range 
(octets) 

Order 

ASN.1  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.1  lASString 

(1-16) 

lexical  order 

ASN.1  GraphicString 

(1-16) 

lexical  order 

ASN.1  GeneralString 

(1-16) 

lexical  order 

ASN.1  OCTET  STRING 

(1-16) 

increasing  value 

ASN.1  GeneralizedTime 

increasing  time  value 

ASN.1  UniversalTime 

increasing  time  value 

NBS-AS1 

FloatingPointNumber 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the  <  KeyPosition>  parameter. 
KeyPosition  =  0  implies  the  key  is  not  part  of  the  data 
position  >  0  specifies  the  actual  data  element  In  the  data  unit. 

\ 

A.7.8      Abstract  syntactic  structure  ^ 

The  abstract  syntactic  structure  of  the  document  Is  a  hierarchically  structured  file  as  defined  in  the  ASN.1  ^ 
module  IS08571-FADU  in  ISO  8571 ,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
structure  of  NBS-ASI  as  defined  by  the  parameters. 

I 

\ 
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A.7.9 


Definition  of  transfer 


A.7.9.1 


Datatype  definitions 


The  file  consists  of  data  values  which  are  of 

a)  Datatypel  defined  In  tatile  11,  where  the  PrimType  In  the  datatype  Is  given  by  the  NBS-ASI 
definition;  or 

b)  Datatype2  defined  In  table  11.  the  ASN.1  datatype  declared  as  "Data-ElemenT  in  the  ASN.l 
module  IS08571-FADU:  or 

c)  Datatypes  defined  In  table  11.  which  specifies  the  user-coded  forni  of  the  Node-Name  in  the 
FTAM  FADU  abstract  syntax,  where  user-coded  is  defined  as  EXTERNAL 


A.7.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  Is 

a)  one  value  of  the  ASN.l  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  Ail  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  In  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2":  or 

c)  a  value  of  "Datatypes'  carrying  a  key.  Ail  values  are  transmitted  in  the  same  (but  any) 
presentation  context  established  to  support  the  abstract  syntax  name  "asnamel ." 


1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  atx>ve  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  In  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 


A.7.9.3       Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  Is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchk:al 
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structure,  when  flattened  according  to  the  definitkxi  of  the  hierarchical  file  model  in  ISO  8571-2.  i 

I 

A.7.10     Transfer  syntax 

An  Implenfientation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named  f| 
in  table  1 1  for  all  presentation  data  values  tran^erred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 

■  '  i 

A.7.11     ASE  specif ic  specif ications  for  FTAM  j 


A.7.1 1 .1      structural  simplification 

This  simplification  loses  information. 

The  document  type  NBS-8  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading  the 
file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transfen'ed  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-8  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading  the 
file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  <  contents  type> 
parameter  on  the  <F-OPEN  request  >.  The  traversal  order  of  the  FADUs  must  be  maintained. 

NOTE  -  Tlie  traversal  order  is  as  reading  the  file  as  NBS-8  in  key  order. 


A.7.1 1.2      Access  context  selection 

A  document  of  type  NBS-8  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  FTAM  ordered 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.7.1 1.3      The  INSERT  operation 

Wfien  the  <  INSERT >  operation  is  applied  the  transferred  material  shall  be  the  series  of  FADUs  which  would 
be  generated  by  reading  any  NBS-8  document  with  the  same  parameter  values  in  access  context  FA. 

The  insertion  of  a  new  FADU  after  an  already  existing  FADU  will  be  indicated  via  a  diagnostic  on  TRANSFER- 
END. 
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A.7.1 1 .4      The  EXTEND  operation 

This  operation  is  ncduded  for  use  with  this  document  type. 

A.8     NBS-9  File  directory  file 
A.8.1       Entry  Number:  NBS-9 
A.8.2      Information  objects 


December  1992  (Stak>le) 
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Table  13  -  Intewnttion  objectt  In  NBS-9 


docufmnl  typ*  nam* 

{iso  IdentHied-organization  oiw(14)  ftamsig(5)  docunf)ent-type(5) 

fileKJiractory(9)} 

*NBS^  FTAM  file  directory  file' 

^tMncH  syntax  namas: 

{iso  IdemifiedKxganization  oiw(14)  1lam8ig(5)  abstract-8yntax(2) 

nb*4«2(2)> 

"NBS  file  directory  entry  abstract  syntax* 

Iranafar  aynlax  namaa: 

pafamalar  aynlax 

PARAMETERS  ::-  [0]  IMPUQT  BIT  STRING  { 

-  Kernel  group 

read-filename  (0), 

read-permitted-actions  (1), 

read-contents-type  (2), 

-  Storage  group 

read-storage-account  (3), 

read-date-and-time-of-creation  (4), 

read-date-and-time-of-last-modlfication  (5), 

read-date-and-time-of-last-read-access  (6), 

read-date-and-time-of-last-attrjt)ute-modification(7), 

read-identity-of-creator  (8), 

read-identity-of-last-modifier  (9), 

read-identity-of-last-reader  (10), 

read-identity-of-last-attribute-modifier  (1 1), 

read-file-availabillty  (12), 

read-fitesize  (13), 

read-future-filesize  (14), 

-  Security  group 

read-access-control  (15), 

read-legal-qualifications  (16), 

-  Private  group 

read-private-use  (17)  } 

fUa  modal 

{iso  standard  8571  file-model(3)  hierarchical(l)} 

'FTAM  hierarchical  file  modeT 

conalfaini  aal 

{iso  standard  8571  constraint-set(4)  unstructured(l)} 

'FTAM  unstructured  constraint  sef 

FHaoontanla: 

Datatypel  ::>  FileDirectoryEntry 

-As  defined  by  NBS-AS2  in  annex  C, 

-C.4  of  this  document 
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A.8.3      Scope  and  field  of  application 

This  document  defines  the  contents  of  a  file  for  transfer  (not  for  storage)  using  FTAI^. 


A.8.4  References 

ISO  8571,  infonnation  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer.  Access  and 
Management. 


A.8.5  Definitions 

This  definition  mai<es  use  of  the  temis  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1 


A.8.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management. 


A.8.7      Document  Semantics 

The  document  consists  of  one  file  access  data  unit,  which  consists  only  of  zero,  one  or  more  data  elements 
of  type  <FileDirectoryEntry>  (defined  in  NBS-AS2). 

The  document  structure  tal<es  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  unstructured  constraint  set.  These  definitions  appear  in  ISO  8571-1. 

The  parameter  of  the  document  type  is  used  on  <  F-OPEN  request  >  to  specify  the  desired  attributes  of  each 
of  the  files  on  the  Filestore,  when  reading  the  document. 


A.8.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  series  of  file  directory  entries,  each  of  which  is  defined 
by  the  <FileDirectoryEntry>  definition  in  NBS-AS2. 

Additional  constraints  are  defined  for  this  document  type:  File  access  actions  are  restricted  to  Read.  Fle- 
directory  files  may  not  be  Written  or  Modified  (except  as  a  side  effect  of  actions  performed  on  individual  files 
contained  within  a  file  directory). 
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A.8.9 


Definition  of  transfer 


A.8.9.1 


Datatype  definition 


The  fie  consists  off  zero  or  more  >^ijes  of  Datatypel  defined  in  table  13. 


A.8.9^       Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  vaiues.  Each  presentation  data  value  shall 
consist  of  one  value  of  the  ASN.1  data  type  'Datatypel carrying  one  of  the  file  directory  entries  from  the 
document. 

All  vsdues  are  transmitted  in  the  same  (t>ut  any)  presentation  context  established  to  support  the  abstract 
syntax  name  "asnamel"  declared  in  table  13. 


A.8.9.3       Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  is  tlie  same  as  the  sequence  of  file  directory  entries  within  ttie 
Data  Unit  In  the  file. 


A.8.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  1 3  for  ail  presentation  data  values  transferred.  Implementations  shall  optionally  support  other  named 
transfer  syntaxes. 


A.8.11     ASE  specific  specifications  for  FTAM 

Relaxation  is  allowed  to  any  bitstring  combination  of  the  document  type  parameter. 
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Annex  B  (normative)   

Constraint  Sets 

B.I     NBS  ordered  flat  constraint  set 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  constraint-8et(4)  nb8-ordered-flat(l)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  NBS  ordered  flat  constraint  set  with  the 
Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set(4)  nbs-ordered-flat(l)} 
defined  in  part  9.  B.2. 

B.2     NBS  ordered  flat  constraint  set  definition 

B.2.1      Field  of  application 

The  NBS-ordered  flat  constraint  set  applies  to  files  which  are  structured  into  a  sequence  of  individual  FAOUs 
and  to  which  access  may  be  made  on  an  FADU  basis  by  position  in  the  sequence. 

B.2.2      Basic  constraints 
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Table  14  -  Basic  constraints  for  NBS  ordered  flat 


noo  Qiuoioa  neu  M^iioiicuiu  otn 

constraint-set(4)  nb&-ordered-flat(1)} 

noQO  naniv 

NonG 

1  ^v^atA  PaqH  InftArt  PrsieA  RAnlaoA 

Qualified  action 

None 

Available  access  contexts 

HA,  FA,  UA 

Creation  state 

Root  node  without  an  associated  data  unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected;  'previous'  gives  last  node  in  traversal  sequence, 
'currenf  and  'nexf  give  an  error. 

Read  whole  file 

Read  in  access  context  FA  or  UA  with  FADU  identity  of  'begin'. 

Write  whole  file  (append) 
WrHe  whole  file  (replace) 

Transfer  the  series  of  leaf  FADUs  v^ich  would  be  generated  by  reading 
the  whole  file  in  access  context  FA;  perform  the  transfer  with  an  FADU 
identity  of  'end'  and  a  file  access  action  of  'inserf . 

Transfer  the  series  of  leaf  FADUs  vt^ich  would  be  generated  by  reading 
the  whole  file  in  access-context  HA;  perform  the  transfer  with  FADU 
identity  'begin'  and  file  action  of  'replace'. 

B.2.3      Structural  constraints 


The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the  root  node  shall  be  leaf  nodes  and 
nnay  have  an  associated  data  unit;  all  arcs  from  the  root  node  shall  be  of  length  one. 


B.2.4      Action  constraints 

Insert:  The  <  Insert >  action  is  allowed  only  at  the  end  of  file.lf  the  FADU  Identity  is  "end"  the  new  node  is 
inserted  following  all  existing  nodes  In  the  file.  If  the  FADU  identity  is  "node  number,"  the  number 
must  be  at  least  one  greater  than  the  node  number  of  the  last  existing  node.  Any  nodes  between 
the  last  existing  node  and  the  new  node  are  empty,  i.e.,  nodes  without  data.  If  the  FADU  identity 
is  a  'node  number"  not  greater  than  that  of  the  last  existing  node,  an  error  will  occur.  The  location 
following  <  insert  >  is  "end." 

Erase:  The  Erase  action  is  only  allowed  at  the  root  node  to  empty  the  file,  with  FADU  Identity  of  "begin." 
The  result  is  a  solitary  root  node  without  an  associated  data  unit. 
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NOTE  •  It  is  the  intention  when  using  this  constraint  set  to  allow  for  emptying  an  FADU,  i.e.,  leaving  an  FAOU 
with  a  DU  of  data  length  0  (or  without  a  DU);  afterwards  data  may  be  reinserted  into  this  hole.  In  order  to 
amply  an  FAOU.  the  <  Replace>  operation  may  be  used  with  new  data  of  length  zero  (or  with  an  FADU  whose 
<data  exists  >  bit  is  set  to  *felse'  and  no  DU).  Refilling  the  hole  is  accomplished  by  a  <  Replace  >  operation 
wHh  the  new  DU  (or  with  the  new  FADU,  whose  <data  exists>  bit  is  set  to  true*  and  the  new  DU). 


B.2.5      Identity  constraints 

The  FAOU  identity  associated  witii  the  file  actior>  shall  be  one  of  the  identities  "t^egin,"  "end,*  first,'  last,' 
'currBTH,'  'next,'  "previous"  or  a  "node  numt>er"  greater  than  or  equal  to  one.  The  actions  with  which  these 
identities  can  be  used  are  given  in  the  following  table. 


Table  1 

15  -  Ment 

tty  constmintt  in  NBS  ordered  flat 

Action 

Begin 

End 

First 

Ust 

Current 

Next 

Previous 

Node  No. 

Locate 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

Read 

wlx>le 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 

Insert 

leaf 

leaf 

Erase 

whole 

Replaoe 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 
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Annex  C  (normative) 
Abstract  Syntaxes 

C.1     Abstract  Syntax  NBS-AS1 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  abstract-syntax(2)  nbs-asl(l)} 

was  witixJrawn  on  March  16, 1990.  It  was  replaced  with  the  object  Abstract  syntax  NBS-ASI  with  the  Object 
Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-asl(l)} 
defined  in  part  9,  C.3. 

C.2     Abstract  Syntax  NBS-AS2 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  abstract-syntax(2)  nbs-as2(2)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  At>stract  syntax  NBS-AS2  with  the  Object 
Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-as2(2)} 
defined  in  part  9,  0.4. 

C.3     Abstract  Syntax  NBS-AS1  definition 

Abstract  syntax  name:  {iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-asl(l)} 

"NBS  abstract  syntax  ASl"  ^ 

This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each  of  which  is  a  value  of  the  ASN.1  type 
NBS-ASI  .PrimType 
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NBS-AS1  DERNinONS 
BEGIN 

PrimType::^  CHOICE 

{ 


INTEGER, 

BIT  STRING, 

BOOLEAN, 

lASStrlng, 

GraphicString, 

GeneralString, 

OCTET  STRING. 

UTCTIme, 

GeneralizedTlme, 

NULL, 

RoatlngPolntNumber } 


The  support  for  lASStrlng  is  the  ISO  646,  IRV  GO 
character  set  and  the  ISO  646,  IRV  CO  set 
The  minimum  level  of  support  for  GraphicString  is 
the  ISO  646,  IRV  GO  character  set  and  the  885&  1 
GO  and  Gl  sets. 

The  minimum  level  of  support  for  GeneralString  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  G1  character  sets,  and  ISO  646,  IRV  CO  set. 


RoatlngPointNumber  [PRIVATE  0]     CHOICE  { 

finite  [0]  IMPUCIT  SEQUENCE 
{  Sign, 

mantissa  BIT  STRING, 
-        first  bit  must  be  1 

exponent  INTEGER}, 
Infinity  [1]  IMPUCIT  Sign, 
signalling-nan  [2]  IMPUCIT  NaN, 
quiet-nan  [3]  IMPUCIT  NaN, 
zero  [4]  IMPUCIT  NULL  } 


Sign         INTEGER  {  positive  (0),  negative  (1)  } 

NaN  INTEGER 

END 


For  this  abstract  syntax  the  following  transfer  syntax  can  be  used 
{joint-iso-ccltt  asn1(1)  basic-encoding(l)} 
'Basic  Encoding  of  a  single  ASN.1  type' 
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NOTES 

1  The  mantissa  is  a  numi^er  in  the  range  (1/2  <mantissa<1). 

2  The  value  is  equal  to  mantissa  *  2  •'"p«^. 

3  The  first  bit  in  the  mantissa  is  most  significant. 

4  See  IEEE  754  for  definitions  of  terminology,  such  as  NaN. 

5  A  minimum  length  range  (in  bits)  is  required  tot  the  components  of  <FloatingPointNumber>,  as  follows: 
mantissa  1-23  bits,  and  exponent  0-8  bits. 

C.4     Abstract  Syntax  NBS-AS2  definition 

Abstract  syntax  nanfie:  {  iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-as2(2)  } 

c        "NBS  file  directory  entry  abstract  syntax" 

This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each  of  which  is  a  value  of  the  ASN.1  Type 
NBS-AS2.FlleDirectoryEntry. 

NBS-AS2  DEFINITIONS  ::  = 
BEGIN 

FlleDirectoryEntry  ::  =  [PRIVATE  2]  Read-Attributes 
Read-Attributes  ::  =  IS08571  -FTAM. Read-Attributes 
END 

For  this  abstract  syntax  the  following  transfer  syntax  will  be  used 
{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type' 


C.5     Abstract  Syntax  "FTAI\1  unstructured  text  abstract  syntax" 

This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)  in  table  19  of  ISO  8571-2,  annex  B. 
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C.6     Abstract  Syntax  "FTAM  unstructured  binary  abstract  syntax" 

This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)  in  tatile  21  of  iSO  8571-2,  annex  B. 
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Annex  P  (informative)  

FTAM-1  Document  Type  Tutorial 


D.I  introduction 

This  ann&K  is  informative,  i!  does  not  specify  any  additional  requirements. 

The  purpose  of  this  tutorial  is  to  describe  methods  to  convey  lines  of  text  in  a  FTAM-1  document  type. 

ISO  8571-2  defines  a  number  of  docun>ent  types  for  flies.  One  of  these  document  types  is  FTAM-1.  ISO 
deflnm  the  FTAM-1  document  type  for  usage  with  flies  that  contain  unstructured  text.  A  flie  tfiat  has  a 
document  type  of  FTAM-1  consists  of  one  FAOU  that  consists  of  zero  or  more  character  strings.  In  order 
to  reduce  ambiguities  it  is  useful  to  assume  that  one  string  corresponds  to  one  Data  Element. 

FTAM-1  document  type  parameters  are  defined  in  ISO  8571-2  clause  B.I.  These  parameters  are  used  to 
define: 

the  allowed  character  sets  that  may  be  contained  in  the  strings  (universal-class-numt>er); 
tfie  maximum  allowed  length  of  a  string  (maximum-string-length); 
the  significance  of  the  boundaries  of  string  (string-significance) 


D.2     Document  type  Parameters 


D.2.1  Universal-Class-Number 

The  universal-class-numt>er  parameter  determines  the  character  sets  that  are  allowed  to  be  used  in  a  FTAM- 
1  file.  The  values  of  the  universal-dass-number  parameter  are  ASN.1  types  whose  definition  can  be  found 
In  ISO  8824.  For  example.  GraphicString,  lASString,  and  GeneralString  are  some  ASN.1  universal  types.  The 
important  thing  for  this  discussion  is  that  some  string  classes  allow  only  graphic  characters  to  be  ined  whie 
other  string  classes  allow  both  graphic  and  control  characters  to  be  used.  ((Control  characters  Include 
"format  effector"  characters  such  as  carriage  retum  <CR>  and  line  feed  <LF>). 


D.2.2  Maximum-Strlng-Length 

The  maximum-string-length  parameter  determines  the  maximum  number  of  characters  allowed  in  a  string 
of  the  FTAM-1  file.  It  does  not  determine  the  maximum  number  of  octets  allowed  in  the  string. 

GeneralStrings  llustrate  how  the  number  of  octets  In  a  string  can  differ  from  the  numtser  of  characters  in 
a  string.  GeneralStrings  can  contain  escape  sequences  that  are  used  for  purposes  such  as  invoking  different 
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character  sets.  An  escape  sequence  is  considered  to  be  a  bit  string,  not  a  character  string.  Therefore,  the 
combined  iength  of  any  escape  sequences  contained  in  a  GeneralString  contributes  to  the  number  of  octets 
in  the  GeneralString  but  does  not  contribute  to  the  number  of  characters  in  the  GeneralString. 

The  length  value  of  the  ASN.1  encoding  of  a  character  string  always  reflects  the  number  of  octets  in  the 
character  string.  This  value  will  always  be  greater  than  or  equal  to  the  number  of  characters  in  the  string. 
The  ASN.1  string  must  be  processed  to  detemnine  the  actual  number  of  characters  in  the  string. 

OIW  FTAM  Phase  2  agreements  state  that  a  conformant  FTAM  implementation  must  support  a  maximum- 
string-length  parameter  of  at  least  134  for  a  FTAM-1  file  (see  part  9  clause  10).  There  Is  no  minimum 
requirement  for  maximum-string-length  in  the  FTAM  pliase  3  agreements.  The  minimum  requirement  Implies 
that  a  minimally  conformant  OIW  FTAM  responding  implementation  will  not  accept  a  FTAM-1  file  whose 
actual  maximum-string-length  parameter  has  a  value  greater  than  134.  The  relaxation  rules  for  FTAM-1  files 
allow  a  FTAM-1  file  to  be  opened  for  read  using  a  maximum-string-length  parameter  that  Is  greater  than  or 
equal  to  the  value  of  the  maximum-string-length  file  attribute  actually  associated  with  the  file,  a  smaller  value 
is  not  allowed  (see  ISO  8571-2  B.I  clause  11.1.1.2).  This  Implies  that  a  minimally  conformant  OIW  FTAM 
initiating  implementation  can  not  read  a  FTAM-1  file  whose  actual  string  length  parameter  has  a  value  greater 
than  134. 

To  increase  interoperability,  a  sending  FTAM  system  should  be  able  to  divide  a  file  with  string-significance 
of  not-significant  into  strings  of  no  more  than  134  characters.  A  receiving  FTAM  system  should  be  able  to 
use  the  strings  to  form  the  file  which  was  sent.  If  a  file  lias  a  maximum-string-length  associated  with  it  that 
is  greater  than  134  interworking  will  not  be  possible  with  a  minimally  conformant  system. 


D.2.3  String-Significance 

The  string-significance  parameter  determines  the  significance  of  the  character  strings  (semantics  of  string 
boundaries).  Fixed  string-significance  means  that  each  string  contains  exactly  the  number  of  characters 
defined  by  the  maximum-string-length  parameter.  Variable  string-significance  means  that  the  length  of  each 
string  is  less  than  or  equal  to  the  maximum-string-length  parameter.  When  string-significance  is  fixed,  then 
maximum-string-len^h  must  be  present.  For  string-significance  of  fixed  or  variable  the  boundaries  of  the 
character  strings  are  preserved  and  contribute  to  the  document's  semantic.  A  value  of  not-significant  means 
that  the  length  of  each  string  is  less  than  or  equal  to  the  maximum-string-length  parameter  and  that  the 
boundaries  of  the  character  strings  are  not  necessarily  preserved  when  the  file  Is  stored  and  do  not 
contribute  to  the  document's  semantics.  In  this  case,  string-significance  may  not  be  maintained,  thus  the 
sender  entity  explicitly  declares  that  string  boundaries  have  no  meaning. 

Note  the  OIW  FTAM  Phase  2  agreements  require  the  support  of  only  the  not-significant  value  for  string- 
significance.  Fixed  and  variable  string-significance  are  outside  the  scope  of  the  Phase  2  agreements,  but 
are  required  in  the  Phase  3  agreements. 

It  is  in  the  area  of  not-significant  strings  where  most  Interoperability  problems  have  occun-ed. 

NOTE  -  the  difference  laetween  variable  significance  and  not-significant  significance.  If  a  file  has  a  significance 
of  fixed  or  variable,  it  is  the  responsibility  of  any  storer  of  the  file  to  "remember"  wrfiere  the  boundaries  of  each 
character  string  are  located  within  the  file.  The  storer  of  a  file  with  a  significance  of  not-significant  has  no  such 
responsibility.  For  example,  virtien  working  with  a  not-significant  file,  the  sending  application  may  find  that  512 
byte  chunks  of  data  is  convenient  and  useful.  The  512  byte  size  may  have  no  relation  to  the  file  layout,  but  is 
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oasy  to  read  from  disk. 

D.3     New  Line  Function 

When  a  sequence  off  characters  are  being  displayed  on  a  character  imaging  device.  e.g..  printer  or  video 
display  terminal  the  term  "new  line  function"  is  used  to  mean  the  repositionir)g  of  the  current  character 
display  position  one  row  down  and  bacic  to  column  one.  A  new  line  function  may  be  implemented  In  a 
variety  of  ways.  A  UNIX  system  implements  the  new  line  function  with  a  <  U^>  character  (sometimes  called 
<NL>).  A  MS-DOS  system  implements  the  new  line  function  with  a  <CR>  <LF>  character  sequence.  A 
typical  word  processor  wfll  implement  a  new  line  function  as  a  "wrap  around'  function  that  depends  upon 
a  defined  page  width.  A  record  oriented  file  system  may  interpret  an  erxi  of  record  condition  as  implying 
a  new  line  function. 

ISO  suggests  (see  ISO  646  clause  4.1.2.2)  that  a  new  line  function  be  accomplished  with  a  <CR>  <LF> 
comt>ination.  If  there  is  a  prior  anangement.e.g..  a  bflaterai  agreen)ent,  between  a  serxJer  and  a  receiver, 
and  only  in  this  case,  may  a  vertical  format  effector,  i.e..  a  <LF>  be  used  to  accomplish  a  new  line  function. 
The  OIW  FTAM  agreements  contain  no  such  prior  arrangement  (see  OIW  Part  9  clause  10.1.2). 

It  is  strongly  suggested  that  files  being  sent  to  a  remote  FTAM  Implementation  represent  the  local  new  line 
function  as  a  <CR><LF>  pair  and  files  received  from  a  remote  FTAM  implementation  have  <CR> <LF> 
pairs  converted  to  the  local  new  line  function.  See  D.5  for  the  reasons  for  this  suggestion. 

It  is  important  to  realize  that  a  new  line  function  represents  a  display  positioning  function  and  it  does  not 
represent  anything  more  that.  A  new  line  function  is  not  intended  to  act  as  either  a  string  terminator  or  a 
string  separator. 

D.4     Character  Strings  Versus  Lines 

A  line  of  characters  is  generally  considered  to  be  a  sequence  of  graphic  characters  followed  by  a  new  line 
function  (or  possibly  by  an  end  of  line  condition). 

A  character  string  is  simply  that,  a  string  of  characters  from  one  or  more  character  sets.  Characters  within 
a  string  come  from  allowed  character  sets.  It  is  the  'universal-class-number"  parameter  defined  in  ISO  8571  -2 
B.I  that  determines  which  character  sets  may  be  used  to  compose  a  string.  For  example,  a  GraphicString 
consists  of  characters  from  any  graphic  character  set  but  may  not  contain  characters  from  a  control 
character  set  ( it  can  not  contain  fomiat  effectors);  a  GeneralString  consists  of  characters  from  any  graphic 
character  set  and  characters  from  any  control  character  set  ( it  can  contain  format  effectors). 

Text  files  will  be  transfen-ed  using  the  Document  type  FTAM-1.  The  supported  character  sets  and  their 
recommended  tine  delimiters  are: 

lASString        (}ine  boundaries  via  fom^t  effectors,  preferably  <CR><LF>) 

GeneralString    (i.e.  ISO  646  Intemational  Reference  Version  and  ISO  8859-1.  Line  boundaries  via 
format  effectors,  preferably  <CR><LF>) 

VisibleString     (lASString  without  control  characters,  line  boundaries  via  Data  Element  boundaries) 
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GraphicString    (i.e.  ISO  646  International  Reference  Version  without  control  characters  and  ISO 
8859-1,  line  boundaries  via  Data  Element  boundaries) 


NOTE  -  A  string  is  really  a  language  (programming  or  otherwise)  concept.  File  systems  generally  have  no 
concept  of  a  string,  although  a  file  system,  especially  a  record  oriented  file  system  may  have  some  concept 
of  a  line. 

The  standard  gives  no  relation  between  character  string  and  a  line  of  characters.  A  character  string  nr^ay 
contain  a  portion  of  a  line  of  characters  or  it  nnay  contain  multiple  lines  of  characters.  A  character  string  can 
contain  zero,  one.  or  many  <CR><IJ^>  pairs.  For  those  character  sets  which  Include  format  effectors,  a 
character  string  may  or  may  not  end  with  a  <CR><LF>  pair.  In  fact,  an  entire  file  of  character  strings  may 
not  contain  a  single  <CR><LF>  pair,  even  when  those  characters  are  allowed  to  be  used  in  the  character 
strings. 


The  following  figure  is  an  example  of  how  lines  of  text  could  be  conveyed  using  lASString  or  GeneralString 
with  string-significance  of  not-significant. 


String-1 

String-2 

String-3 

String-4 

String-5 

Une-1 

<CR><LF> 

Une-2 

<CR><LF> 

Line-3 

<CR><LF> 

Line-4 

<CR><LF> 

Line-S 

<CR><LF> 

The  following  figure  is  an  example  of  how  lines  of  text  could  be  conveyed  using  VisibleString  or 
GraphicString  with  string-significance  of  fixed  or  variat>le. 


String-1 

String-2 

String-3 

String-4 

String-5 

Une-1 

Une-2 

Une-3 

Une-4 

Une-5 

I 

-I 


I  D.5     Mapping  FTAM-1  Files  to  Real  Files 

The  lack  of  equivalence  between  a  line  of  characters  and  a  character  string  can  cause  implementation 

problems.  It  is  common  for  a  record  oriented  file  system  to  store  a  line  of  characters  as  a  record.  How  does 
I  such  a  system  decide  how  large  a  record  to  allocate  for  a  line  of  characters?  A  line  of  characters  may  be 

contained  in  a  part  of  one  string,  one  or  more  strings,  or  it  may  actually  consist  of  an  entire  file.  How  does 
{  such  a  system  identify  the  end  of  a  line  (record)?  It  must  scan  the  string  for  a  <CR><U=>  pair  (or  end  of 
1  transmission)  and  probat>ly  remove  the  <CR><LF>  before  storing  a  record.  What  happens  if  the  line  Is 

bigger  than  the  size  of  the  record  allocated?  The  system  would  likely  break  the  string  and  store  it  in  the 
I  available  record  size.  In  this  case,  the  FTAM-1  document  type  should  not  be  used  to  transfer  this  file  when 
I  the  sender  is  not  sensitive  to  the  receiver's  limitations. 

i  Another  problem  can  occur  when  a  system  whose  new  line  function  is  implemented  by  a  <CR  ><  LF>  pair 
sends  a  file  to  a  system  whose  new  line  function  is  implemented  by  <  LF> .  For  example,  a  MS-DOS  system 
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could  send  a  fie  that  contains  <CR>  <LF>  pairs  and  also  contains  single  <LF>  characters  to  a  UNIX 
system.  The  UNIX  system  would  likely  translate  txjth  <CR><LF>  and  <LF>  to  UNIX  new  line  functions, 
i.e.  a  <LF>.  In  this  case,  the  FTAM-1  document  type  should  not  be  used  to  transfer  this  type  of  file. 


D.6     Printing  or  Displaying  a  File  without  Format  Effectors 

There  Is  no  relation  between  a  character  string  and  a  line  of  characters  (see  ISO  8571  -2  B.I  clause  7)  except 
wfien  character  strings  that  come  from  chara^er  sets  that  do  not  contain  format  effector  characters  (for 
example,  VislbleStrings  and  GraphicStrings)  are  transferred  to  a  device  such  as  a  printer.  In  this  case  the 
end  oif  a  string  Implies  the  invocation  of  the  device's  new  line  function.  This  means  that,  in  this  case,  a  string 
Is  equivalent  to  a  line. 

The  rerxJition  of  such  a  file  made  of  character  strings  belonging  to  a  set  that  does  not  contain  format  effector 
characters  (for  example,  VlsibieString,  and  QraphlcString)  to  be  transfen-ed  first  to  disk  and  then  to  a 
character  Imaging  devtee  might  not  be  equivalent  to  the  rendition  of  the  same  file  transferred  directly  to  a 
character  imaging  devtee. 


72 


stable  Implementation 
Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  1 0  -  FTAM  Phase  3 


Output  from  the  December  1992  Open  Systems 
Environment  Implementors'  Workshop  (OIW) 


I  BIG  Chair:        Joe  Mohen,  Proginet 

■  SIG  Editor:        Larry  Friedman,  Digital  Equipment  Corporation 

I 


PART  10  -  FTAM  Phase  3 


December  1992  (Stable) 


Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  File  Transfer,  Access  and 
Management  Special  Interest  Group  (FTAM  SIG)  of  the  Open  Systems  Environment  Implementors' 
Workshop  (OlW).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change  from  this  text  as 
previously  given.  References  to  Part  9  are  made  in  this  part. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Edttor't  Note  -  The  "NBS"  designation  remains  in  effect  for  document  types,  abstract  syntaxes,  and  constraint 
sets  defined  in  all  FTAM  agreements  up  to  1/1/89.  After  1/1/89,  any  new  functionality  references  ttie  'NlSr 
designation.  This  is  to  reflect  the  change  in  identifying  organization  from  "NBS"  to  "NIST." 


l\  This  dause  contains  Implementors  Agreements  based  on  ISO  8571  File  Transfer,  Access  and  Management. 
I  These  Agreements  define  enhancements  to  the  Stable  FTAM  Implementation  Agreements  for  OSI  Protocols, 
[  Version  1.  Edition  1.  December  1987  (FTAM  Phase  2  Agreements,  NBS  500-150),  Including  all  their 
j  subsequent  Errata  changes  through  Version  4,  Edition  1  (NIST  Special  Publication  500-183,  this  document 
part  9). 

1  Therefore  It  Is  assumed  that  the  reader  Is  familiar  both  with  the  contents  of  the  base  standard  ISO  8571  and 
!!  Its  underlying  layers,  and  also  with  the  atx)ve-mentloned  NIST  FTAM  Phase  2  specifications. 

Phase  2  Agreements  define  six  implementation  Profiles  which  are  T1,  T2,  T3,  A1,  A2,  and  Ml.  In  order  to 
I  j  avoid  ambiguity  when  referring  to  these  Implementation  Profiles  the  above  designations  will  apply  only  to 
Phase  2  functionality,  references  to  Phase  3  enhanced  Implementation  Profiles  will  be  by  the  addition  of  a 
".3,"  i.e.,  T1.3,  T2.3,  T3.3.  A1.3,  A2.3.  and  Ml. 3. 

The  following  clauses  specify  the  functionality  of  OIW  FTAM  Phase  3: 

a)  Clauses  1  and  8  specify  the  technical  details  of  FTAM  Phase  3  which  are  defined  in  addition  to 
the  functionality  of  FTAM  Phase  2.  Included  is  also  a  status  overview  regarding  statements  on 
Phase  2/Phase  3  compatibility  and  interworking; 

b)  Annex  A  is  a  Profile  Requirements  List  for  the  Implementation  Profiles  T1 .3,  T2.3,  A1 .3  and  Ml  .3, 
summarizing  all  features  of  FTAM  Phase  3,  Including  those  of  FTAM  Phase  2.  This  Profile 
Requirements  Ust  is  fully  based  on  the  FTAM  PICS  Proforma  ISO  8571-5; 

c)  Annex  B  Is  an  index  of  Object  Identifiers.  It  is  the  official  NIST  OIW  Register  of  NIST  OIW 
defined  FTAM  objects.  It  contains  the  Object  Descriptors  and  Object  Identifiers  for  these  objects, 
Including  a  reference  to  the  clause  in  the  NIST  OIW  Stable  Agreements  where  the  respective  object 
is  being  defined; 


Introduction 


d)  Annexes  C,  D,  and  E  provide  definitions  for  additional  document  types,  constraint  sets  and 
abstract  syntaxes; 
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1  Scope 

These  Phase  3  Agreements  specify  additional  functionality  to  the  FTAM  Phase  2  Agreements.  These 
additional  functions  include: 

Further  specifications  of  document  types; 

Specification  for  Restart  Data  Transfer  and  Recovery  functional  units; 

Specificatton  of  FAOU  Loci<ing  functional  unit; 

More  details  on  Access  Control  and  Concurrency  Control. 

All  Phase  2  systems  are  upward  compatit>le  to  a  Phase  3  system  and  can  therefore  inteiwork  with  it.  if  the 
additional  functions  are  negotiated  out  (e.g.,  use  dS  Recovery)  or  not  used  for  the  interconnection  (e.g., 
addittonal  features  for  document  types). 


2    Normative  References 

Amendments  and  corrigenda  to  the  base  standards  referenced:  See  annex  G  for  a  complete  list  of  these 
documents. 

ISO  8571-1:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  1:  General  Introduction 

ISO  8571-2:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  2:  Virtual  Filestore  Definition 

ISO  8571-3:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  arid  Management  Part  3:  The  File  Service  Definition 

ISO  8571-4:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  4:  File  Protocol  Specification 
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3  Status 

I  These  FTAM  Phase  3  Agreements  were  completed  December  15,  1989.  No  further  enhancements  will  t>e 
I  made  to  this  version  (see  also  next  clause  ERRATA). 

I  The  following  tables  summarize  the  functions  and  features  which  are  defined  for  FTAM  Phase  3  in  addition 
i  to  the  FTAM  Phase  2  specifications.  They  also  state  the  degree  of  possit)le  inten^orking  and  the  bacl<ward 
compatibility. 


Table  1  -  Phase  2/Pha8e  3  Interworking 


Additionai  requirements  in  FTAM  phase  3 


Backward  compatibility  to 
FTAM  phase  2 


FTAM-1:  GraphlcString.VisibleString 


full  backward  compatit}ility  if  the 
additional  features  of  Phase  3 
are  not  being  used  (character 
sets  in  FTAM-1 ,  -2),  or  not 
requested  by  an  Initiator 
(functional  units)  or  not 
required  by  a  Responder 
(parameters)  not  requested  by 
an  Initiator  (functional  units) 


FrAM-2:  VisibleString 


create-password  parameter  for  Initiator 


Profile  Ml. 3:  Requires  support  of 


Management  FU.  Enhanced  FM  FU; 
TM  sen/ice  class  including  Enhanced  FM  FU  or 
(2)-A  sen/ice  dass  including  Limited  File 
Management  FU,  Enhanced  FM  FU 
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 Tabte  1  -  PhiM  2/Ph«f  3  Intenworklng  (continued)  


toFTAM  pha8e2 

FTAM-2:  Gen«ralString,  lASString 

FTAM-4 

NBS-8  in  T2.3.  A1.3 

NBS-9in  A1.3.  A2.3 

NBS-10 

NBS-11 

NBS-12 

Recovory  functional  unit 

ne8iaii*aaiariiansrei  lundioriai  unn 

FADU-locking  functional  unit  and  FADU-lock  parameters  in  A1.3,  A2.3 
Concurrency-corrtroi  parameter  for  Initiator 

lull  uaCKWaiQ  oornpaHiDnny  n  uiw 

additioruy  features  of  PhM«  3  are  not 
requested,  negotiated  out  or  not  being 
used 

Concurrency-corrtrol  parameters  for  Responder 

create-password  parameter  for  Responder 

location-field  of  access-control  element 

suggested-delay  term  of  diagnostic  parameter  supported  conditioruUly  on 
Recovery  functional  units 
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Table  1  -  Phase  2/Pha8e  3  Interworking  (concluded) 


Relaxation  for  FTAM  phase  3 


Backward  compatibility  to  FTAM  phase 
2 


Profiles  A1 .3,  A2.3  do  not  require  transfer  service  class 

no  minimum  requirements  for  maximum-string-length  parameters  for  document 
types 


if  T  service  class  not  being  used 

if  a  Phase  3  system  stays  below  this 
minimum  requirement 


4  Errata 


Table  2  -  List  of  Errata 


No.  of 
errata 

Type 

Referenced 
document 

Clause 

Description 

CP  3/91-1 

Editorial 

NIST-SP  500-183 

All 

Update  to  ISO  style.  General 
formatting  and  error  corrections. 
Alignment  with  the  wording  of  the  ISP. 
Consistent  naming  conventions. 

CP  6/91-1 

Editorial 

NIST-SP  500-183 

8.6.1 

A.  13.9. 1.2 
A.13.9.1.3 
A.13.9.1.4 

Previous  errata  changed  the  Profile 
Requirements  List  (PRL)  support  of 
Concurrency  Control  from  "m"  to  'o". 
This  change  was  not  reflected. 

Alignment  with  the  ISP. 
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No.  of 

Type 

Referenced 

Qause 

 1  — .  ™., 

Description 

errata 

document 

! 

CP  9/91-1 

Editorial 

NiST  SP  500-183 

Talsle  4 

Include  FTAM  In  object  descriptor 

for  consistency  with  otiier  OIW 

FTAM  objects. 

CP  9/91-2 

Table  5 

Add  definition  for  Datatypes 

CP  9/91-2 

Table  8 

Delete  last  line  of  Write  Wliole  File 

[previous  change  incomplete]. 

CP  9/91-3 

Ctause  2 

Add  reference  to  corrigenda. 

CP  9/91-4 

A.12.16.1 

A.12.16.5 

Support  level  from  "o"  to  "m".  Add 

A.12.17.1 

note  that  must  support  at  least  one 

A.12.17.5 

action.  Add  note  about  supporting 

at  least  one  optional  FU. 

CP  9/91-5 

A.  13.6.1 

Criange  to  spelling  of  ASN.l  text 

A.  13.6.2 

types. 

CP  9/91-6 

C.2.7 

Changes  to  add  Datatypes  to  text 

C.2.9.1 

descriptions 

C.2.9.2 

CP  9/91-7 

C.1.11.1 

"Structural  SimpHfication"  to 

C.2.11.1 

Simplification 

C.3.11.1 

CP  9/91-8 

E.1 

Changed  "will"  to  "can" 

E.2 

E.3 

CP  9/91-9 

Annex  B 

Added  Editors  note  of  intention  to 

remove  object  definitions  when  the 

ISP  is  published. 

CP  9/91" 

Added  Annm  G 

New  annex  to  list  corrigenda 
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5  Conformance 

In  addition  to  the  specific  requirements  specified  in  the  following  8ut)clause8.  confonnance  to  this  Phase 
3  specification  requires 

confomnance  to  ISO  8571 : 1988 

confonnance  to  Phase  2  FTAM,  unless  specified  otherwise  in  this  part  10. 

The  access  Profles  A1 .3  and  A2.3  do  not  include  the  requirement  for  transferring  files  using  the  Fie 
Transfer  service  class. 


6  Assumptions 

FTAM  Phase  3  Agreements  specify  additional  functionality  to  the  implementation  Profiies  T1,  T2.  T3.  A1. 
A2,  and  Ml  as  defined  in  the  FTAM  Phase  2  Agreements.  So  all  definitions  and  requirements  for  thtese 
implementation  Profiies  apply  also  to  the  Phase  3  Agreements. 


7    Filestore  Agreements 


7.1      Document  Types 

in  addition  to  the  Phase  2  Document  Type  Agreements  the  document  types  FTAM-4  (see  ISO  8571-2. 
Annex  B)  and  NBS-10.  NBS-11.  NBS-12  (see  Annex  C)  are  defined  for  optional  support. 

Table  2  gives  the  support  levels  for  all  document  types  with  respect  to  the  implementation  Profiles. 

For  FTAM-1.  FTAM-2.  FTAM-3  and  FTAM-4  the  supported  parameter  values  for  <  universal  dass 
numt>er>  and  <  string  significance  >,  respectively  are  listed.  Other  values  are  outside  the  scope  of  these 
Agreements.  No  re^rictlon  or  minimum  requirement  is  defined  for  the  <  maximum  string  length  > 
parameter  of  these  document  types. 
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Table  3  -  Implementation  Profiles  and  Document  Types  -  FTAM-1  Through  FTAM-4 


Implementation  Profile 
(Note  1) 

Document 
Type 

Universal  Class  Number 
(Notes  1.3.4,5) 

String  Significance 

T1  3  T2  3  T3  3  A1  3  A2  3 

FTAM-1 

GraohicStrirui  (2Si 

'variable'  'fixed' 

VisibleStrina  (26) 

'variable'  'fixed' 

GeneralString  (27) 

'not-significanf 

lASString  (22) 

'not-significanf 

T2.3,  T3.3,  A1.3.  A2.3 

FTAM-2 

QraphicString  (25) 

'not-significanf 

VisibleString  (26) 

'not-significanf 

[GeneralString  (27)] 

'not-significanf 

[lASString  (22)] 

'not-significanf 

T1.3.  T2.3,  T3.3.  A1.3,  A2.3 

FTAM-3 

'not-significanf 

[T2.3],  [T3.3].  [A1.3]. 
IA2.3] 

FTAM-4 

'not-significanf 

Table  3  -  Implementation  Profiles  and  Document  Types  -  NBS-6  Through  NBS-11  (continued) 

Implementation  Profile  (Note  1) 

Document  Type 

[T2.3],  T3.3,  [A1.3],  A2.3 

NBS-6 

[T2.3].  T3.3.  [A1.3].  A2.3 

NBS-7 

[T2.3],  T3.3,  [A1.3],  A2.3 

NBS-8 

[T1.3],  [T2.3],  [T3.3],  [A1.3],  [A2.3] 

NBS-9 

[T2.3].  [T3.3],  [A1.3].  [A2.3] 

NBS-1G 

[T2.3],  [T3.3].  [A1.3].  [A2.3] 

NBS-11 
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Table  3  -  ImplemenUition  ProfliM  and  Documant  TypM  -  NBS-12  (concluded) 


Implementation  profile 
(Note  1) 

Document  type 

Universal  dau  ruunber 

Character-set  escape 
sequences  as  defined  for 
reg.  numbers 
CO       GO  G1 

String-significartoe 

[T2.3J.  [T3.3]. 

NBS-12 

lASString  [22] 

(parameter  absent) 



'variable'  'fixed*  1 

(A1.31. 
IA2.31 

GraphicStrIng  [25] 

(parameter  absent) 

'variable'  'fixed* 

See  Note  6 

GraphicString  [25] 

6  100 

'variable'  'fixed* 

VisibleString  [26] 

(parameter  absent) 

'variable'  'fixed* 

GeneralString  [27] 

(parameter  absent) 

•variable'  'fixed* 

GeneralStrIng  [27] 

1         6  100 

'variable'  'fixed* 

NOTES 

1  Brackets  around  a  Profile  designator  or  a  parameter  value  indicate  that  the  respective  document  type  or  parameter  value  is 
optionally  supported  in  this  Implementation  Profile. 

2  The  support  level  for  document  types  in  Implementation  Profile  Ml. 3  depends  on  the  T-  or  A-lmplementation  Profile,  in 
conjunction  with  which  Ml. 3  is  implemented. 

3  The  support  for  IA5  String  is  the  ISO  646.  IRV  GO  character  set  and  the  ISO  646.  IRV  CO  set 

4  The  minimum  level  of  support  for  Graphic  String  is  the  ISO  646.  IRV  GO  character  set  and  the  8859-1  GO  and  G1  sets. 

5  The  minimum  level  of  support  for  General  String  is  the  ISO  646.  IRV  GO  character  set  and  the  8859-1  GO  and  G1  sets,  and  ISO 
646.  IRV  CO  set 


6  If  the  Character-Set  parameter  is  absent,  the  following  defouKs  apply: 


Universal-class-numt>er 

DefouH  registration  numbers 
CO       GO  G1 

IA5Strlng  [22] 
GraphicString  [25] 
VisibleString  [26] 
GeneralString  [27] 

1  2 
2 
2 

1  2 
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1  Registration  number 

Content 

Escape  Sequence  | 

1  ^ 

1  ^ 

CO  set  of  ISO  646 
ISO  646,  IRV 

ISO  646.  USA  Version-X  3.4-1966  (Left-hand  part  of  ISO  8859- 
1) 

Right-hand  part  of  Latin  Alphabet  No  1  ISO  8859-1.  ECMA-94 

ESC  2/1  4/0  1 
ESC  2/8  4/2  1 

1 

ESC  2/13  4/1  1 

7.2      FADU  Identities 

In  addition  to  the  Phase  2  FADU  Identity  Agreements  the  following  is  specified: 

For  the  document  type  NBS-1 1  used  in  conjunction  with  the  Transfer  service  dass  or  the 
Transfer  and  Management  service  class,  the  support  of  the  FADU  identities  of  "current,"  "next," 
"prevbus"  and  "end"  is  outside  the  scope  of  these  Agreements. 


7.3     Access  Control  Attribute 

The  location  field  of  access  control  element  Is  optionally  supported.  It  is  the  implementor's  choice  which 
combinations  of  fields  in  an  access  control  element  are  supported.  The  ACE  combination  should  be 
stated  in  the  PICS. 


8     Protocol  Agreements 


8.1      Implementation  Profile  Ml  .3 

The  functions  defined  for  the  Implementation  Profile  M1.3  shall  always  be  implemented  in  conjunction 
with  one  or  more  of  the  implementation  Profiles  T1.3,  T2.3,  A1.3,  or  A2.3.  The  service  classes  and 
functional  units  that  shall  be  implemented  are  specified  in  Annex  A,  A.  12.4  and  A.  12.5. 

For  an  implementation  supporting  the  Profile  Ml. 3  in  conjunction  with  T1.3  or  T2.3,  any  of  the  service 
classes  Transfer,  Management  or  (Transfer,  Management,  Transfer-and-Management)  may  be  requested 
and  any  of  the  classes  Transfer,  Management,  Transfer-and-Management  may  be  responded  on  F- 
INITIAUZE. 

For  an  implenf>entation  supporting  the  Profile  Ml. 3  in  conjunction  with  A1.3  or  A2.3,  any  of  the  service 
classes  Access  or  Management  may  be  requested  and  responded  on  F-INITIALIZE. 
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For  FTAM  Phase  3  implementations  Recovery  and  Restart  Data  Transfer  are  optionaliy  supported. 
FADU  ioclcing  is  optionaiiy  supported  for  implementation  Profiles  A1.3  and  A2.3. 


8.3     Implementation  Information  Parameter 

In  addition  to  the  Agreements  as  specified  for  FTAM  Phase  2.  part  9  clause  12  ,  the  following  value  Is 
defined 

NBS-Phase3. 


8.4  F-Check 

In  order  to  maximize  interoperat>ility,  implementations  of  FTAM  service  providers  should  not  restrict  the 
amount  of  data  transmitted  t)etween  successive  F-CHECK  requests  to  a  single  quantity.  Variations  in  the 
amount  of  data  transmitted  t>etween  checlcpolnts  may  be  required  to  accommodate  differences  in  real 
end  systems  supporting  FTAM  Virtual  FUestores  and/or  in  the  communications  media  underlying  FTAM 
associations.  It  is  required  that  all  FTAM  imp)lementatlons  are  able  to  receive  at  least  one  PSDU 
between  checkpoints. 


8.5     Error  Recovery 

Procedures  for  Class  I,  II  and  ill  errors  are  defined  and  supported  for  FTAM  Phase  3  implementations.  It 
is  the  implementor's  choice  whether  to  handle  class  I  errors  using  F-RESTART  PDUs  or  whether  to  use 
the  dass  11  error  procedure. 


8.5.1       Docket  Handling 

When  a  dass  III  en'or  occurs,  the  length  of  time  a  doci<et  is  maintained  is  determined  by  the  local 
system.  Recovery  from  a  dass  III  error  is  only  possible  as  long  as  both  end  systems  maintain  the 
docl<et. 

It  is  also  a  local  decision  how  many  dockets  can  be  maintained  simi^neously. 


8.5.2       Parameters  for  Error  Recovery 

The  following  information  is  given: 

The  semantics  of  the  <FTAM  quality  of  service  >  parameter  Is  as  defined  in  ISO  8571;  induding 
the  local  knowledge  of  FERPM; 
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No  minimum  requirement  for  tiie  <checl<point  window>  parameter  or  tlie  ctiecl<point  size  is  < 
defined: 

For  the  <  recovery  mode>  parameter  of  F-OPEN,  the  values  "none"  and  "at-start-of-transfer"  are 
supported.  The  value  "at-anynactive-checkpoint'  is  optionally  supported.  If  recovery  mode  "at- 
start-of-transfer"  is  negotiated,  no  F-CHECK  shall  be  issued.  When  recovering  at  the  start  of  the  | 
transfer,  the  <  recovery  point >  value  of  0  shall  be  used; 

It  is  required  that  Responders  implementing  the  Restart-data-transfer  or  the  Recovery  functional  ' 
unit  must  be  able  to  negotiate  <  recovery  mode>  parameter  to  a  value  other  than  "none";  < 

i 

For  the  <diagnostlc>  parameter  of  F-INITIAUZE,  F-P-ABORT  and  F-RECOVER  PDUs,  the  terni  • 
<  suggested  delay  >  shall  be  supported  if  the  Recovery  functional  unit  is  implemented.  The 
Basic  FERPM  should  wait  at  least  the  amount  of  time  as  given  by  the  <  suggested  delay  >  term  > 
before  attempting  to  recover.  ' 


8.6     Concurrency  Control 


8.6.1       Concurrency  Control  to  whole  file 

If  <  concurrency  control  >  parameters  are  supported,  details  of  their  possible  usage  is  a  local  matter  and 
shall  be  specified  in  the  PICS. 

Default  values  for  concurrency  control  are  as  specified  for  FTAM  Phase  2  Agreements. 

No  minimum  requirement  is  defined  for  <  concurrency  control  >  parameter  values. 

For  a  first  accessor  either  the  specified  concurrency  locks  or  the  default  values  are  assigned.  For  a 
subsequent  accessor  the  access  to  a  file  is  granted  only  if  this  concurrency  control  requirement,  as 
specified  in  this  concurrency  control  parameter  or  given  by  the  default  values,  can  be  met.  Otherwise 
the  subsequent  request  shall  be  rejected. 


8.6.2        FADU  Locking 

FADU  locking  functional  unit  and  the  respective  <FADU  lock>  parameters  are  optionally  supported  for 
the  Implementation  Profiles  A1.3  and  A2.3. 

It  is  understood  that  ISO  8571-4  Clause  18.4  also  applies  to  FADU  locks;  that  means  that  as  long  as  a  I 
docket  is  maintained,  FADU  locks  locking  any  FADUs  recorded  in  that  docket  should  be  maintained. 
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8.7     Create  Password 

The  < create  password  >  parameter  for  an  implementation  acting  as  an  Initiator  is  supported.  This 
parameter  is  optionally  supported  for  an  implementation  acting  as  a  Responder. 


8.8     initiator  Identity,  Passwords  and  Account 

An  Initiator  must  be  capable  of  sending  and  not  sending  the  parameters  <  initiator  identity  >,  <  filestore 
password  >.  <  access  passwords  >  and  <  create  password  >  to  satisfy  the  requirements  of  the 
Responder. 

The  contents  of  the  <  initiator  identity  >,  <  filestore  password  >.  <  access  passwords  >,  <  create 
password  >  and  <  account  >  parameters  shall  be  in  the  convention  of  the  responding  implementation. 


9    Range  off  Values  for  Integer-Type  Parameter 

In  addition  to  the  parameters  specified  for  FTAM  Phase  2  under  the  same  heading,  the  parameters 


F-RECOVER  request 

bulk-transfer-number 
NBS-AS3 
NBS-Node-Name 

starting-fadu 

tadu-count 

may  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  eight  octets. 


.1 
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Aniwx  A  (normative) 
Profilo  Requirements  List 


Editor't  Note  -  Tho  page  numbering  of  the  PICs  tables  may  not  be  aligned  with  the  text  of  this 
document.  The  reason  for  this  problem  is  that  the  PICs  tables  are  coded  using  a  different  wordprocessor. 
The  tables  are  being  converted,  but  until  this  is  completed  the  page  numbering,  and  format  of  the  tables 
may  be  aligned  with  the  text  of  this  document. 


In  the  event  of  a  discrepancy  becomming  apparent  in  the  body  of  these  agreements  and  the  tables  in 
this  annex,  this  annex  is  to  take  precedence. 

Editor't  Note  -  Delete  lines  A.13.9.1.2,  A.13.9.1.3,  A.13.9.1.4,  when  the  PICS  tables  are  converted  to 
WordPerfect  Version  5.1  fbmiat. 

Editor't  Note  •  Change  table  A.S  to  reference  Annex  G.  See  ISO/IEC  ISP  10607-4:1990  A.5.  When 
Annex  A  is  converted  to  WordPerfect  VS.1. 


Editor't  Note  -  A.I2.I6.I,  A.I2.I6.5.  A.12.17.1,  and  A.12.17.5  replace  the  'o'  with 'm'  in  the  A1.3  column. 
Add  a  note  to  tables  A.12.16  and  A.12.17  'For  the  profile  A1.3,  the  support  of  at  least  one  of  insert,  replace, 
or  extend  is  required.*  Also  add  a  note  to  tables  A.12.16  and  A.12.17  '  For  profiles  T1.3  and  T2.3,  the 
support  of  at  least  one  of  read,  insert,  replace  or  extend  is  required.'  When  Annex  A  is  converted  to 
WordPerfect  VS.1. 


Editor't  Note  -  A.13.6.1,  and  A.13.6.2  change  parameter  names  to  'Universal  time,'  'Generalized  time,' 
•|A5String,"  'Boolean,'  'Bit,'  'Integer."  When  Annex  A  is  converted  to  WordPerfect  V5.1. 
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PART  10  -  FTAM  Phase  3 


December  1992  (Stable) 


Annex  A 

(normative) 

Profile  Requirements  List  for  NIST  0«W  FTAM  Phase  3 


A.0  Introduction 

This  annex  to  NIST  FTAM  Phase  3  Agreements  defines  a  Profile  Requirements  List  (PRL)  for  the  Implementation 
Profiles 

T1.3    -     Simple  File  Transfer 
T2.3    -     Positional  File  Transfer 
A1 .3    -     Simple  File  Access 
M1.3  -  Management 


This  annex  specifies  the  constraints  and  characteristics  of  NIST  OIW  FTAM  Phase  3  on  what  shall  or  may  appear  in 
the  supplier  columns  of  an  FTAM  Phase  3  PICS.  This  annex  is  completely  based  on  ISO  8571-5.  K  uses  only  a 
selection  of  the  tables  from  ISO  8571-5  which  are  necessary  for  the  specification  of  the  FTAM  Phase  3  status,  and 
retains  their  numbering,  in  order  to  facilitate  for  a  supplier  to  fill  in  the  respective  PICS  Proforma. 

This  annex  is  a  summary  of  all  definitions  of  FTAM  Phase  3  as  they  appear  in  the  Stable  Implementation  Agree- 
ments for  OS!  Protocols,  Version  4  Edition  1,  December  1990,  parts  9  and  10. 


A.0.1  Conformance  requirement  of  Base  Standards 

The  D-column  of  clauses  A.1  to  A.13  specifies  the  conformance  requirement  of  the  base  standards  ISO  8571,  as 
written  in  ISO  8571-5.  The  definitions  apply  as  defined  in  ISO  8571-5  clause  8.1  : 

m  -    mandatory  support 
o    -  optional  support 
f     -  full  support  of  attributes 
p    -  partial  support  of  attributes 
-  not  applicable 

A  single  value  in  the  D-column  applies  to  the  Initiator  role  of  a  system  as  well  as  to  the  Responder  role.  If  two 
values  are  specified  in  the  D-column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Responder 
(R)  role,  respectively. 


.  A.0.2  Conformance  requirement  of  Profiles 

The  Conformance  requirement  of  the  Implementation  Profiles  is  specified  in  the  "Profiles'  column/columns,  in  clauses 
A.I  to  A.13.  The  following  convention  is  applied  for  this  purpose  : 

0  a  'PROFILES'  column  is  valid  for  all  Profiles  T1 .3,  T2.3,  A1.3  and  Ml  .3 

0   if  different  conformance  requirements  apply  to  different  Profiles,  separate  columns  are  included  in  the  tables,  each 
bearing  the  corresponding  Profile  name  as  its  heading,  or  separate  tables  for  these  Profiles  are  used 
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0   a  single  value  in  these  columns  applies  to  the  Initiator  as  well  as  to  the  Responder  role  of  an  implementation 

o   if  two  values  are  specified  in  a  column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Re- 
sponder (R)  role,  respectively. 

For  the  conformance  requirements  of  the  NIST  FTAM  Phase  3  Profiles  the  following  abbreviations  are  used. 

mandatory;  m : 

This  is  a  mandatory  or  optbnal  feature  in  the  base  starxiard.  h  shall  be  supported,  i.e.,  its  syntax  and  procedures 
shall  be  implemented  as  specKied  in  the  base  standard  or  in  FTAM  Phase  3  by  all  implementations  claiming 
conformance  to  the  Profile.  i 

I 

However,  it  is  not  a  requirement  that  the  feature  shall  be  used  in  all  instances  of  communication,  unless  mandated  ^ 
by  the  base  standard  or  stated  otherwise  in  FTAM  Phase  3. 

For  fully  supported  attributes,  this  implies  that  at  least  the  minimum  range  of  attribute  values,  as  defined  in  ISOj 
8571-2,  shall  be  supported  unless  stated  otherwise  in  FTAM  Phase  3.  | 

Also  for  features  which  are  optional  in  the  base  standard,  conformant  implementations  shall  be  able  to  interwork 
with  other  implementations  not  supporting  this  feature.  « 

The  support  of  a  feature  can  be  conditional,  depending  on  the  support  of  a  class  of  features  to  which  it  belongs, 
e.g.,  an  attribute  in  an  attribute  group,  a  parameter  in  a  PDU,  a  PDU  in  a  functional  unit. 

optional;  o:  ' 

It  is  left  to  the  implementation  as  to  whether  this  feature  is  implemented  or  not. 

If  an  attribute  group  with  a  support  level  of  'o'  is  chosen  to  be  supported,  then  all  the  attributes  in  this  group  that  are  ■ 
classified  as 'm'  shall  be  supported. 

The  support  for  POUs  is  determined  by  the  negotiation  of  functbnal  units  when  the  connection  is  established. 

If  a  parameter  is  optionally  supported,  then  its  syntax  shall  be  implemented,  but  it  is  left  to  each  implementation 
whether  its  procedures  are  implemented  or  not. 

When  receiving  an  optional  parameter  which  is  not  subject  of  negotiation  and  is  not  supported  by  the  Receiver,  the 
Receiver  shall  at  least  inform  the  Sender  by  informative  diagnostic  and  interworking  shall  not  be  disrupted. 

conditional;  c : 

This  feature  shall  be  supported  under  the  conditions  specified  in  FTAM  Phase  3.  If  these  conditions  are  not  met,  the^ 
feature  is  outside  the  scope  of  the  Profile. 

excluded;  x : 

This  feature  is  excluded  from  the  Profile.  The  implementor's  answer  in  the  PICS  shall  always  be  'no', 
outside  the  scope;  I : 

This  feature  is  outside  the  scope  of  the  Profile,  i.e.,  it  may  be  ignored,  and  will  therefore  not  be  subject  of  a  Profile 
conformance  test.  However  the  syntax  of  all  parameters  of  supported  PDUs  shall  be  implemented,  even  if  their 
procedures  are  not  (i.e.,  the  Receiver  shall  be  able  to  decode  the  PDU). 

not  applicable;  - : 

This  feature  is  not  defined  in  the  context  where  it  is  mentioned,  e.g.,  a  parameter  which  is  not  part  of  the  respective  i 
PDU.  The  occurrence  of  'not  applicable'  features  is  mainly  due  to  the  format  of  the  tables  in  the  Phase  3  Profiles 
Requirements  List. 


i 
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Section  1 

A.1  (void) 
A.2  (void) 

Section  2:  General  ISO  8571  Detail 

A.3  ISO  8571  Protocol  versions 


FTAM  protocol  version  number(s) 

version>1 

A.4  ISO  8571  Addenda 

ISO  8571-1 

ISO  8571-2 

ISO  8571-3 

ISO  8571-4 

ISO  8571-5 

A.5  Defect  report  numbers  and  amendments 


ISO  8571-1 

ISO  8571-2 

ISO  8571-3 

ISO  857M 

ISO  8571-5 

A.6  Global  statement  of  conformance 


Does  FTAM  Phase  3  conform  to  ISO  8571  ?  yeS 
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A.7  Initiator  /  Responder  capability 

ROLES 

D 

PRORLES 

i  R 

Sender 

0 

o  o 

Receiver 

0 

o  e 

NOTE  •  See  part  9  18.1 


A.8  Application  Context  Name  details 


ISO  8571 •4  definee  a  value  for  a  aimple  transfer  mechanism.  Other  values  are  not  defined  for  FTAM  Phaae  3 
(aee  part  9  5.9). 
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Section  3  :  Syntax  Detail 

A.9  Abstract  syntaxes 


Object  Descriptor 

UDjoct  loentitior 

D 

T1.3 

T2.3 

A1 .3 

M1.3 

1 

FTAMPO 

{iso  standard  8571  abstract-syntax(2) 
ftam-pci(l) } 

m 

m 

m 

m 

m 

2 

FTAM  FADU 

{iso  standard  8571  abstract-syntax(2) 
ftam-fadu(2) } 

0 

i 

m 

m 

i 

3 

{joint-iso-cdtt  association-control(2) 
abstract-syntax(l)  apdus(O)  version1(1) } 

m 

m 

m 

m 

m 

4 

FTAM  unstructured 
text  abstract  syntax 

(iso  standard  8571  abstract-syntax(2) 
unstructured-text(3) ) 

0 

m 

m 

m 

• 

S 

FTAM  unstructured 
binary  abstract  syntax 

(iso  standard  8571  abstract-syntax(2) 
unstructured-binary(4) } 

0 

m 

m 

m 

6 

NBS  file  directory 
entry  abstract  syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
at>straci-syntax(2)  nbs-as2(2) ) 

c 

c 

c 

7 

NBS  abstract 

syntax  ASI 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-asl(l) } 

i 

c 

c 

S 

NBS  random  access 
node  name  abstract 
syntax 

.  {iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-node-name(3) } 

i 

c  c 

see  clause  9 

9 

NBS  random  binary 
access  file  sbstract 
syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-random-binary(4) } 

i 

c 

c 

1C 

NBS  simple  text 
abstract  syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-simple-text(5) } 

i 

c 

c 

NOTES 

1  The  abstract  syntaxes  which  are  supported  in  the  Implementation  Profile  Ml. 3  depend  on  the  T-or  A-Profile  in  conjunction  with 
which  Ml  .3  is  implemented. 

2  The  support  requirements  for  the  conditional  abstract  syntaxes  depend  on  the  constraint  sets  and  document  types  which  are 
implemented  (see  clause  A.  13). 

3  ISO  8571  requires  the  presence  of  the  transfer  syntax  derived  from  the  'Basic  Encoding  of  a  single  ASN.1  type  "(joint-iso-ccitt 
asm  (1)  basic-encoding  (1)}  encoding  rules  for  transfer  of  the  "FTAM  PC!"  and  the  "FTAM  FADU"  abstract  syntaxes.  Implementa- 
tion detail  of  this  transfer  syntax,  and  other  transfer  syntaxes  supported,  is  specified  in  the  PICS  of  ISO  8823. 
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Section  4  :  Virtual  Filestore  Detail 


A.10  Virtual  filestore 

This  clause  details  the  conformance  to  the  file  model,  file  attribute  support  and  to  file  structure  support. 
A.I 0.1  File  model 


RLE  MODEL 

D 

PI^OFILES 

R 

Hierarchical 

0 

m 

Other  models  i 

A.  10.2  Attributes 

A.1 0.2.1  Attribute  groups 


ATTRIBUTE  GROUP  NAME 

D 

PROFILES 

1 

Kernel 

m 

m 

2 

Storage 

0 

o 

3 

Security 

0 

o 

4 

Private 

0 

i 

A.1 0.2.2  Attribute  values 


KERNEL  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

1 

1 

Filename 

f 

m 

see  A.10.2.3 

2 

Permitted  Actions 

s 

m 

• 

3 

Contents  Type 

f 

m 

see  A.  12.7 

i 

[ 

KERNEL  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full 

RANGE  OF  VALUES 

4 

Filename 

f 

m 

see  A.10.2.3 

5 

Permitted  Actions 

f 

m 

B 

Contents  Type 

f 

m 

see  A.  12.7 
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STORAGE  GROUP 
(INITIATOR) 

D 

PROFILES 
Ifull 

RANGE  OF  VALUES 

7 

Storage  account 

f 

m 

1 

File  availability 

f 

m 

• 

Future  filesize 

f 

m 

see  part  9  1 7  9 

NOTE  -  An  initiator  shall  not  partially  support  attributes 

STORAGE  GROUP 
(RESPONDER) 

D 

PRORLES 
R  full              R  partial 

RANGE  OF  VALUES 

10 

Storage  account 

P 

o 

o 

11 

Date  and  time  of  creation 

P 

o 

o 

12 

Date  and  time  of  last  modification 

P 

o 

o 

13 

Date  and  time  of  last  read  access 

P 

o 

o 

14 

Date  and  time  of  last  attribute  modification 

P 

o 

o 

IS 

Identity  of  creator 

P 

o 

o 

16 

Identity  of  last  modifier 

P 

o 

o 

17 

Identity  of  last  reader 

P 

o 

o 

18 

Identity  of  last  attribute  modifier 

P 

o 

0 

19 

File  availability 

P 

m 

X 

30 

Filesize 

P 

m 

X 

see  part  9  1 7.9 

21 

Future  filesize 

P 

o 

o 

see  part  9  17.9 

SECURITY  GROUP 
(INITIATOR) 

D 

PROFILES 
Ifull 

RANGE  OF  VALUES 

Access  control 

f 

m 

see  A.  12.2 

Legal  qualifications 

f 

m 

NOTE  -  An  initiator  shall  not  partially  support  atbibutes 

SECURITY  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full             R  partial 

RANGE  OF  VALUES 

Access  control 

P 

m  X 

see  A. 12. 2.  pan  9  9.2 

Legal  qualifications 

P 

o  o 
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See  part  9  9.1 


A.1 0.3  Rie  Structures 
A.I  0.3.1  Constraint  sets 


CONSTRAINT  SET  NAME 

D 

T1.3 

T2.3 

A1.3 

M1.3 

Unstnjctured 

0 

m 

m 

m 

Sequential  Fiat 

0 

m 

m 

Ordered  flat 

0 

o 

o 

Ordered  flat  with  unique  names 

e 

o 

0 

Ordered  hierarchical 

0 

1 

1 

General  hierarchical 

0 

1 

1 

General  hierarchical  with  unique  names 

0 

1 

1 

NBS  ordered  flat 

o 

o 

NBS  random  access 

o 

o 

A.1 0.3.2  File  and  filestore  actions 
A.1 0.3.2.1  Filestore  Actions 


Support  for  filestore  actions  is  dependent  upon  the  functional  units  implemented  (see  A.1 2.4  and  A.1 2.5) 

A.10.3.2.2  File  Actions 

RESPONDER 

CONSTRAINT  SET 
unstructured 

ACTION 

D  T1.3 

Locate   

Read 

0  0 

Insert   

Replace 

0  o 

Extend 

0  o 

Erase 

0  1 
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CONSTRAINT  SET 

flat 

ordered 
flat 

ordered  flat 
with  unique 
names 

noo 
ordered 
flst 

random 
access 

ACTION 

D  T2.3 

D  T2.3 

D 

T2.3 

D 

T2.3 

D  T2.3 

D  T2.3 

7 

Locate 

0  i 

0 

1 

0 

1 

i 

i 

I 

Read 

0  o 

0  o 

o 

o 

0 

o 

o 

o 

• 

Insert 

0  0 

0 

o 

0 

o 

o 

o 

10 

Replace 

0  o 

0 

o 

0 

o 

o 

o 

11 

Extend 

0  o 

0 

o 

0 

o 

12 

Erase 

0  1 

0  i 

0 

1 

0 

1 

1 

1 

CONSTRAINT  SET 

RESPONDER 

unstructured 

sequential 

ordered 

ordered  flat 

NBS 

NBS 

with  unique 

ordered 

random 

flat 

Hat 

names 

flat 

access 

ACTION 

D  A1.3 

D  A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

D  A1.3 

Locate 

0  o 

0 

o 

0 

0 

o 

o 

Read 

0  o 

0  o 

0 

o 

0 

o 

o . 

o 

Insert 

0  o 

0 

o 

0 

o 

o 

o 

Replace 

0  o 

0 

o 

0 

o 

0 

o 

Extend 

0  o 

0 

o 

0 

o 

Erase 

0  o 

0  o 

0 

0 

0 

o 

o 

o 

NOTE  -  File  actions  are  not  defined  in  Implementation  Profile  M1.3 


t 
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A.I  0.3.2.3  Access  contexts  supported  ;^ 


CONSTRAINT  SET 

RESPONDER 

unstructured 

ACCESS  CONTEXT 

D  T1.3 

1 

US   

2 

UA 

0  m 

3 

FS   

4 

FL   

5 

FA   

6 

HN   

HA   

CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 
flat 

ordered 
flat 

ordered  flat 
with  unique 
names 

NBS 
ordered 
flat 

NBS 
random 
access 

ACCESS  CONTEXT 

D     T2.3         D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

US 

a 

9 

UA 

o       m          0  m 

0  m 

0  m 

m 

m 

10 

FS 

11 

FL 



12 

FA 

0  m 

0  m 

m 

  0  m 

13 

HN 

14 

HA 

0  o 

0  o 

f 
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CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 

ordered 

ordered  flat 

NBS 

NBS 

flat 

with  unique 

ordered 

random 

flat 

names 

flat 

access 

ACCESS  CONTEXT 

D     A1.3         D  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

US     

UA 

0      m         0  m 

0  in 

0  m 

m 

m 

FS 

FL 

FA 

  0  m 

o  m 

0  m 

m 

HN 

HA 

0  o 

0  o 

o 

NOTE  -  The  supported  access  contexts  lor  Impementation  Profile  Ml  .3  are  defined  in  the  T-  or  A-Profile  in  conjunction  with  which 
I      Ml. 3  is  implemented. 

i 

I    A.10.4  Additional  information 

( Void ) 


y    A.I 0.5  Override 


RESPONDER  OVERRIDE 

D 

PROFILES 
R 

1 

Create  failure 

0 

m 

2 

Select  old  file 

0 

m 

3 

Delete  and  reaeate  with  old  attributes 

0 

o 

4 

Delete  and  create  with  new  attributes 

0 

m 

NOTE  -  The  specification  of  the  role  of  initator  is  given  in  A.  1 2. 1 5. 
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Section  5  :  File  Protocol  Detail 

A.1 1  File  protocol 

See  part  9  clauses  5.1  -  S.3  and  17 

Subclauses  A.11.2  to  A.1 1.24  specify  an  indication  of  which  PDUs  are  supported.  The  conformance  requirements 
for  POUs  are  dependent  on  the  particular  functional  units  implemented.  PDUs  indicated  in  A.1 1.8  to  A.1 1.24  as 
conditional  shall  be  considered  as  mandatory  when  a  particular  functional  unit  is  implemented,  according  to  the 
following  table. 


PDUs 

Clause 

Functional  Units 

Ker- 
nel 

Read 

Write 

Ac- 
cess 

LFM 

EFM 

Grou- 
ping 

Reco- 
very 

Re- 
start 

r-OHcAlh 

A.  1  1 .8 

m 

r-DcLcTc 

A  4  4  A 

A.1  1  .9 

m 

C  DCAr\   A  1  1  DID 

r-HcAU-AI  1  nib 

A.1 1.10 

m 

r-OMANot-A  1  IMIb 

A.1  1.11 

m 

Ail  1 0 

A.  1  1 . l£ 

m 

m 

F-CLOSE 

A.11.13 

m 

m 

F-BEGIN-GROUP 

A.11.14 

m 

F-END-GROUP 

A.11.15 

m 

F-RECOVER 

A.11.16 

m 

F-LOCATE 

A.11.17 

m 

F-ERASE 

A.11.18 

m 

F-READ 

A.11.19 

m 

F-WRITE 

A.  11. 20 

m 

F-DATA-END 

A.1 1.21 

m 

m 

F-TRANSFER-END 

A.1 1.22 

m 

m 

F-CANCEL 

A.1 1.23 

m 

m 

F-RESTART 

A.1 1.24 

m 

NOTES 

1  In  order  to  keep  the  protocol  tables  compact  some  forward  references  have  been  introduced  to  clauses  which  expand  upon  the 
detail  of  field  support. 


2  The  FTAM  protocol  will  require  a  number  of  optional  lower  layer  services  to  be  available  (e.g.,  Application  Entity  Titles  in  ACSE). 
This  requirement  is  outside  the  scope  of  this  Profiles  Requirements  List. 
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(  Void  ) 

A.11.2  FTAM  regime  establishment 


1 

D 

R 

PROFILES 
1  R 

1 

F-INITIAUZE  PDU 

m 

m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

4 

Protocol  version 

m 

m 

m  m 

see  Section  2 

5 

Implementation  information 

0 

0 

o  o 

see  A.1 2.1 

6 

Presentation  context  management 

m 

m 

m  m 

see  note  1,  part  9  17.10 

7 

Service  class 

m 

m 

m  m 

see  A.  12.4 

8 

Functional  units 

m 

m 

m  m 

see  A.12.5 

V 

Attrihi  ito  nrminc 

m 

m 

m  Tt\ 

coo  A  m  9 

10 

Shared  ASE  information 

0 

0 

1  1 

see  part  9  5.8 

n 

FTAM  Quality  of  Service 

m 

m 

m  m 

see  A.  12.8 

12 

Contents  type  list 

0 

0 

m  m 

see  A.12.7.1.  part  9  18.4 

13 

Initiator  identity 

0 

m 

see  8.8.  part  9  16.1  and  18  4 

14 

Account 

0 

o 

see  8.8,  part  9  18  4 

IS 

Filestore  password 

0 

m 

see  A.12.11,  8.8,  part9  16.1 

16 

Diagnostic 

0 

m 

see  A.I 2.6.  8.5.2,  part  9  13 

17 

Checkpoint  window 

m 

m 

m  m 

see  note  2,  8.5.2 

NOTES 

1  The  values  available  for  the  presentation  context  management  field  depend  upon  the  functional  units  implemented  in  ISO  8323. 

2  Checkpoint  window  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  the  value  1. 
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PART  10  -  FTAM  Phase  3 

A.11.3  FTAM  regime  termination  (orderly) 


December  1992  (Stable) 


D 
1  R 

PROHLES 
1  R 

F-TERMINATE  PDU 

m  m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Shared  ASE  information 

0  o 

1  1 

see  part  9  5.6 

Chevging 

-  0 

-  o 

see  A.12.10 

A.11.4  FTAM  regime  termination  (abrupt)  by  service  user 

D 

PROFILES 

F-U-ABORT  PDU 

m 

m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

Diagnostic 

0 

m 

see  A.12.6,  part  9  13 

A.11.5  FTAM  regime  termination  (abrupt)  by  service  provider 


D 

PROFILES 

F-P-ABORT  PDU 

m 

m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

Diagnostic 

0 

m 

see  A.12.6.  8.5.2.  part  9  13 
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A.11.6  File  selection 


December  1992  (Stable) 


D 
1  R 

PRORLES 
1  R 

1 

F-SELECT  PDU 

m  m 

m  m 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

4 

Attributes 

m  m 

m  m 

see  A. 10.2,  part  9  17.9 

S 

Requested  access 

m 

m 

see  A  12.16 

6 

Access  passwords 

0 

m 

see  8.8,  part  9  16.2 

7 

Concurrency  control 

0 

o 

see  A.12  13,  8.6.1 

8 

Shared  ASE  information 

0  0 

1  1 

see  part  9  5.8 

9 

Account 

o 

o 

see  8  8,  part  9  18  4 

10 

Diagnostic 

0 

m 

see  A  12.6,  part  9  13 

A.11.7  File  deselection 

D 
1  R 

PROFILES 
1  R 

\ 

F-DESELECT  PDU 

m  m 

m  fn 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

m 

•  m 

all  values  defined  in  ISO  8571 

3 

Charging 

0 

-  o 

see  A.12. 10 

4 

Shared  ASE  information 

0  0 

1  i 

see  part  9  5.8 

S 

Diagnostic 

0 

-  m 

see  A.  12.6,  part  9  13 
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A.11.8  File  creation 


D 

1  B 

PROFILES 
1  R 

^ 

F-CREATE  PDU 

c  c 

e  c 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

-  m 

•  n 

all  values  defined  in  ISO  6571 

3 

Action  result 

-  m 

•  m 

all  values  defined  in  ISO  6571 

4 

Override 

m  - 

m  - 

see  A.12.15 

5 

Initial  attributes 

m  m 

m  m 

see  A.10.2.  part  9  10.2.2.17.9 

6 

Create  password 

0 

m  - 

see  A.  12. 12.  8.7.  8.6. 
part  9  16.2 

7 

Requested  access 

m  - 

m  - 

see  A.12.16 

e 

Access  passwords 

0 

m  - 

see  6.6.  part  9  16.2 

9 

Concurrency  control 

0 

o  • 

see  A.  12. 13,  8.6.1 

10 

Shared  ASE  information 

0  0 

1  1 

see  part  9  5.8 

11 

Account 

0 

o  • 

see  8.8.  part  9  18.4 

12 

Diagnostic 

0 

-  m 

see  A.12.6.  part  9  13 

A.11. 9  File  deletion 


D 
1  R 

PROFILES 
1  R 

1 

F-DELETE  PDU 

c  c 

c  c 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

-  m 

-  m 

all  values  defined  in  ISO  8571 

3 

Shared  ASE  information 

0  0 

1  1 

4 

Charging 

-  0 

-  o 

see  A.12.10 

S 

Diagnostic 

-  0 

m 

see  A.12.6.  part  9  13 

i 
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A.11.10  Read  attributes 


December  1992  (Stable) 


D 
1  R 

PRORLES 

1  D 

t 

C  6 

c  c 

see  A.1 1,  A.  12.3 

HELD  NAME 

OR  REFERENCE 

2 

Action  result 

-  m 

-  m 

all  values  defined  in  ISO  B571 

3 

Attribute  names 

m  - 

m  - 

4 

Attributes 

-  0 

•  m 

see  A.  10.2,  part  9  17.9 

S 

Diagnostic 

-  0 

•  m 

see  A.12.6.  part  9  13 

A.1 1 .11  Change  attributes 


D 
1  R 

T1.3,  T2.3,  A1.3 

Ml  .3 
1  R 

1 

F<CHANGE-ATTRIB 

c  c 

1 

m  m 

see  A.11,  A.12.5 

RELO  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Acton  result 

-  m 

1 

-  m 

all  values  defined  in  ISO  8571 

1 

Attributes 

m  0 

I 

m  m 

see  A.  10.2.  part  9  17.9 

4 

Diagnostic 

-  0 

1 

m 

see  A.12.6,  part  9  13 

A.1 1.12  RIeopen 


D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

Ml  .3 

1 

F-OPEN  POU 

c  c 

m  m 

1 

see  A.11,  A.12.5 

RELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

m 

-  m 

1 

all  values  defined  in  ISO  8571 

3 

Action  result 

-  m 

-  m 

1 

all  values  defined  in  ISO  8571 

4 

Processing  mode 

m 

m  - 

1 

see  A.12.17 

5 

Contents  type 

m  m 

m  m 

1 

see  A.12.7.2 
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6 

Concurrency  control                    o  o 

o  o 

i 

oLJvJ  n.  1        1  vl,  0.\J,  1 

7 

onaroo  Aoc  iniormaiion                  o  o 

1 

8 

Enable  FADU  locking                   m  .  - 

m  - 

1 

•false'  for  T1 .3  and  T2.3 

9 

Activity  identifier                        o  - 

o 

i 

10 

Diagnostic                               -  o 

m 

1 

see  A.12.6,  part  9  13 

11 

Recovery  mode                        m  m 

m  m 

! 

see  A.  12.18 

12 

Remove  contexts                       o    -                  1    -  ! 

13 

Define  contexts                         o    -                   1   -  i 

14 

Presentation  action                     -  m 

"  m 

i 

see  note 

NOTE  -  The  values  depend  upon  the  functional  units  implemented  in  ISO  8823. 

A.11.13  File  Close 

D 

T1.3,  T2.3,  A1.3 

Ml. 3 

1 

F-CLOSE  PDU  c 

m 

1 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result  m 

m 

1 

all  values  defined  in  ISO  8571 

3 

Shared  ASE  information  o 

1 

1 

see  part  9  5.8 

4 

Diagnostic  o 

m 

1 

see  A.12.6,  part  9  13 

A.11.14  Beginning  of  grouping 

D 
1  R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

1 

F-BEGIN-GROUP  PDU                 c  c 

m  m 

o  o 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Threshold                                m  - 

m 

m  - 

A.11.15  End  Of  grouping 

D 

T1.3,  T2.3 

A1.3 

F-END-GROUP  PDU  c 

m 

o 

see  A.11.  A.12.5 

The  F-END-GROUP  PDU  carries  no  fields. 
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A.1 1.16  Regime  recovery 


December  1992  (Stable) 


See  8.5 


D 
1  R 

T1.3,T2.3,  A1.3           Ml. 3 
1  R 

1 

F-RECOVER  PDU 

c  c 

c  c                      i                    see  A.11,  A.12.5 

RANGE  OF  VALUES 

RELD  NAME 

OR  REFERENCE 

2 

State  result 

m 

m                    1                   all  values  defined  in  ISO  8571 

3 

Action  result 

-  m 

-    m                    1                   all  values  defined  in  ISO  8571 

4 

Activity  identifier 

m  - 

m    •  i 

s 

Bulk  transfer  number 

m 

m    •                     i                    see  clause  9 

6 

Requested  access 

m  - 

tn    •                    1                   see  A.12.16 

7 

Access  passwords 

0  - 

m    °                    1                   see  8.8,  part  9  16.2 

8 

Contents  type 

-  m 

-    m                   i                   see  A.  12.7.2 

9 

Recovery  point 

m  m 

m    m  1 

10 

Diagnostic 

-  0 

•    m                    i                   see  A.I 2.6,  8.5.2.  part  9  13 

11 

Remove  contexts 

o  - 

i    •                     i                   see  notes 

12 

Define  contexts 

0  - 

i    •                     1                   see  notes 

13 

Presentation  action 

-  m 

•    m                    1                   see  notes 

NOTES 

1  The  values  available  for  the  presentation  action  field  depend  upon  the  functional  units  implemented  in  ISO  6823. 

2  Presentation  action  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4  The  field  is  defaulted  to  no  action. 

A.11.17  Locate  file  access  data  unit 

D 
1  R 

T1.3.T2.3          A1.3          Ml. 3 
1  R 

1 

F-LOCATE  PDU 

c  c 

i                  mm!               see  A  ll,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

-  m 

i                       m            i                  all  values  defined  in  ISO  8571 

3 

FADU  identity 

m  0 

1                   m    o           i                  see  part  9  17.9 

4 

FADU  lock 

0  - 

1                  o    •            i                 seeA.12  14 

S 

Diagnostic 

-  0 

1                   -ml                  see  A  12.6,  part  9  13 
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A.11 .1 8  Erase  file  access  data  unit 


December  1992  (Stable) 


1 

D 
R 

T1.3,  T2.3 

A1.3 
1  R 

Ml. 3 

F-ERASE  PDU 

c 

c 

1 

m  m 

1 

see  A  ll.  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

1 

-  m 

1 

all  values  defined  in  ISO  8571 

FADU  identity 

m 

1 

m  - 

! 

see  part  9  17.9 

Diagnostic 

0 

1 

-  m 

1 

see  A.  12.6,  part  9  13 

A.11. 19  Read  bulk  data 

1 

D 
R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

M1.3 

F-READ  PDU 

c 

c 

c  c 

m  m 

1 

see  A  ll.  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

FADU  identity 

m 

m  - 

m  - 

1 

see  part  9  17.9 

Access  context 

m 

m  - 

m  - 

1 

see  A.  10.3.2.3 

FADU  lock 

0 

1 

o 

i 

A.11.20  Write  bulk  data 

1 

D 
R 

T1.3,T2.3 
i  R 

A1.3 
1  R 

M1.3 

F-WRITE  PDU 

c 

c 

c  c 

m  m 

1 

see  A  ll.  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

FADU  operation 

m 

m  - 

m  - 

i 

FADU  identity 

m 

m 

m  - 

i 

see  pan  9  17.9 

FADU  Lock 

0 

i 

o 

i 

PART  10  -  FTAM  Phase  3 

A.1 1 :21  End  of  data  transfer 


December  1992  (Stable) 


D 

T1.3,T2.3,  A1.3 

Ml. 3 

F-DATA-END  PDU 

c 

m 

1 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m 

1 

ail  values  defined  in  ISO  8571 

Diagnostic 

0 

m 

1 

see  A.12,6,  part  9  13 

A.1 1.22  End  Of  transfer 

1 

D 
R 

T1.3,T2.3,  A1.3 
i  R 

M1.3 

F-TRANSFER-END  PDU 

c 

c 

m  m 

1 

see  A  ll.  A.12.5 

rlcLD  NAMc 

RANGE  OF  VALUES 
On  rlcrtncNwc 

Action  result 

m 

-  m 

8 

all  values  defined  in  ISO  6571 

Shared  ASE  information 

0 

0 

i  1 

1 

see  part  9  5.8 

Diagnostic 

0 

-  ID 

1 

see  A.  12.6,  part  9  13 

A.1 1.23  Cancel  data  transfer 

See  part  9  clause  11 

D 

T1.3.T2.3,  A1.3 

Ml  .3 

F-CANCEL  PDU 

c 

m 

1 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m 

i 

all  values  defined  in  ISO  8571 

Shared  ASE  infontiation 

0 

1 

1 

see  part  9  5.8 

Diagnostic 

0 

m 

1 

see  A.  12.6,  part  9  13 

A.11.23.1  F-CANCEL  mapping 

See  part  9  clauses  11  and  17.10 
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A.1 1 .24  Restart  data  transfer 


D 

T1.3,  T2.3,  A1.3 

M1.3 

F-RESTART  PDU 

c 

c 

1 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Checkpoint  identifier 

m 

m 

1 

A.1 2  Expanded  PDU  field  and  filestore  detail 

This  clause  identifies  further  PDU  field  and  filestore  detail  to  expand  on  that  given  in  A.10  and  A.1 1. 
A.1 2.1  Implementation  information  detail 

j  See  8.3,  part  9  5.6  and  12 

A.1 2.2  Access  control  detail 


See  7.3,  part  9  9.2 


Access  control  element  terms 

D 

PROFILES 

RANGE  OF  VALUES 

Action  list 

m 

m 

Concurrency  access 

0 

o 

see  A.  12.3.3 

Identity 

0 

0 

Passwords 

0 

o 

see  A.12.3.5.  A.12.3.6.  8.8 

Location 

0 

o 

A.1 2.3  Access  control  element  detail 
A.1 2.3.1  Action  list  detail  (initiator) 

(  Void  ) 

A.1 2.3.2  Action  list  detail  (responder) 

(  Void  ) 
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A.1 2.3.3  Concurrency  access  term 

If  the  concurrency  access  term  is  supported  in  the  access  control  eiement  the  following  details  of  the  concurrency 
control  shall  be  available  with  each  action. 


T1.3 
Action 

not  required 
D  T1.3 

shared 
D 

T1 .3 

exclusive 
D  T1.3 

no  access 
D  T1.3 

0 

o 

0 

o 

o 

o 

o 

o 

Insert 

0 

i 

0 

1 

0 

1 

o 

1 

Replace 

o 

o 

0 

o 

0 

o 

0 

o 

Extend 

o 

o 

0 

o 

o 

o 

o 

o 

Erase 

0 

i 

0 

1 

0 

i 

0 

1 

6 

Read  attributes 

0 

o 

0 

o 

0 

o 

0 

o 

7 

Change  attributes 

0 

1 

0 

i 

o 

1 

o 

i 

8 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 

T2.3 
Action 

not  required 
D  T2.3 

shared 
D 

T2.3 

exclusive 
D  T2.3 

no  access 
D  T2.3 

9 

Read 

0 

o 

0 

o 

0 

o 

0 

o 

10 

Insert 

0 

o 

0 

0 

0 

o 

0 

o 

11 

Replace 

0 

o 

0 

o 

0 

o 

0 

o 

12 

Extend 

0 

o 

0 

o 

0 

o 

0 

o 

13 

Erase 

o 

1 

0 

1 

0 

1 

0 

i 

14 

Read  attributes 

G 

o 

0 

o 

0 

o 

0 

o 

15 

Change  attributes 

0 

1 

0 

i 

0 

i 

0 

1 

16 

Delete  file 

O 

o 

0 

o 

0 

o 

0 

o 
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December  1992  (Stable) 


A1.3 
Action 

not  required 
D  A1.3 

shared 
0 

A1.3 

exclusive 
D  A1.3 

no  access 
D  A1.3 

Read 

o 

o 

0 

o 

0 

O  - 

0 

o  ' 

K 

insert 

o 

o 

0 

o 

0 

0 

0 

o 

19 

Rsplaos 

0 

o 

0 

o 

0 

e 

0 

o 

20 

Extend 

0 

o 

0 

o 

0 

o 

0 

o 

21 

Erase 

0 

o 

0 

o 

0 

0 

0 

o 

22 

Read  attributes 

0 

0 

0 

o 

0 

o 

0 

o 

23 

Change  attributes 

0 

1 

0 

i 

0 

1 

0 

1 

24 

Delete  file 

9 

® 

Q 

© 

0 

o 

0 

o 

M1.3             not  required 
Action  D 

M1.3 

shared 

D 

M1.3 

exclusive 
D 

no  access 
Ml  .3  D 

M1.3 

2S 

Read 

0 

1 

0 

0 

0 

1 

26 

Insert 

0 

1 

0 

0 

0 

1 

27 

Replace 

0 

0 

0 

0 

28 

Extend 

0 

0 

0 

0 

2S 

Erase 

© 

0 

0 

0 

30 

Read  attributes 

0 

o 

0 

e 

0 

o 

0 

o 

31 

Change  attributes 

0 

o 

0 

o 

0 

o 

0 

o 

32 

Delete  file 

0 

o 

0 

0 

0 

o 

0 

o 

A.1 2.3.4  Identity  term 

(Void) 


A.I  2.3.5  Initiator  access  passwords 


If  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
initiator  role. 

^  See  part  9  16.3  


Initiator  Access  Passwords 

D 

PROHLES 
1 

1 

OctetString 

0 

o 

2 

GraphicString 

0 

o 
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A.1 2:3.6  Responder  access  passwords 

If  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
responder  role. 


See  part  9 

16.3 

Responder  Access 
Passwords 

0 

T1.3 
OctetString 
GraphicStrIng 

T2.3 
OctetString 
GraphicStrIng 

A1  3 
OctetString 
GraphicStrIng 

M1.3 
OctetString 
GraphicStrIng 

1 

Read-password 

0 

o 

o 

O 

1 

2 

Insert-password 

0 

1 

o 

o 

1 

3 

Replace-password 

0 

o 

o 

o 

! 

4 

Extend-password 

0 

o 

o 

o 

i 

S 

Erase-password 

0 

1 

1 

o 

1 

6 

Read-attribute-password 

0 

o 

o 

0 

0 

7 

Change-attribute-password 

0 

1 

1 

o 

e 

Delete-password 

0 

o 

o 

o 

0 

A.1 2.3.7  Location  term 

( Void ) 

A.1 2.3.7.1  Application  Entity  Titles  detail 

See  part  9  5.7 


A.1 2.3.8  Access  control  element  combinations 


Combinations 

D 

PROFILES 
R 

1 

Identity 

Password 

Location 

0 

o 

2 

Identity 

Password 

0 

o 

3 

Identity 

Location 

0 

0 

4 

Password 

Location 

0 

o 

5 

Identity 

0 

o 

6 

Password 

0 

0 

7 

Location 

0 

o 

NOTE  -  Implementation  of  access  control  without  any  of  the  above  combinations  is  valid 
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A.12.4  Service  class  field  detail 

 See 5.1, 8.1. part 9  table?  


D 

T1  J,  T2.3 

A1.3 

iyi1.3(T) 

Ml  .3  (A) 

Transfer  dass 

0 

m 

1 

m 

i 

Access  dass 

0 

m 

1 

m 

Management  dass 

0 

1 

1 

m 

m 

Transfer  and  management  dass 

0 

o 

m 

Unconstrained  dass 

0 

1 

1 

1 

NOTES 

1  The  jnitiator  is  only  permitted  to  spedfy  those  combinations  defined  in  ISO  8571-3 

2  The  notation  M1.3(T)  in(icates  M1.3  combined  with  a  Transfer  Profile  T1.3  or  T2.3.  M1.3(A)  means  M1.3  combined  with  the 
Access  Profile  A  1.3. 


i; 
i 

A.12.5  Functional  unit  field  detail 


See  8.1, 8.2,  part  9  table  7 


T1.3,T2.3 

SERVICE  CLASSES 

Transfer 

Transfer  and  Management 

FUNCTIONAL  UNITS 

D 

T1.3,  T2.3 

D 

T1.3,  T2.3 

Kernel 

m 

m 

m 

m 

Read  (see  note  2) 

c 

® 

e 

o 

Write  (see  note  2) 

c 

o 

c 

o 

File  Access     

Limited  RIe  Management 

0 

o 

m 

m 

Enhanced 

File  Management 

0 

1 

0 

i 

Grouping 

m 

m 

m 

m 

FADU  Locking 

Recovery 

0 

o 

0 

o 

Restart 

0 

o 

0 

o 

NOTES 

1  The  recovery  and  the  restart  functional  units  are  only  available  at  the  internal  file  service  interface  and  should  only  be  explicitly 
referenced  in  the  protocol. 

2  The  c  indicates  that  either  or  both  of  the  read  and  write  functional  units  shall  be  implemented  in  the  particular  service  dass. 
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A1.3 

FUNCTIONAL  UNITS 

SERVICE  CLASSES 
Access 
D  A1.3 

11 

Kernel 

m 

m 

12 

Read 

m 

m 

13 

Write 

m 

m 

14 

File  Access 

m 

m 

15 

Limited  File  Management 

0 

o 

16 

Enhanced 

File  Management 

0 

1 

17 

Grouping 

0 

o 

16 

FADU  Locking 

0 

o 

see  8.6.2 

19 

Recovery 

0 

o 

20 

Restart 

0 

o 

See  8.1 

M1.3(T) 

FUNCTIONAL  UNITS 

SERVICE  CLASSES 
Transfer  Management 
D      M1.3(T)       D  M1.3(T) 

Transfer  and  Management 
D  M1.3(T) 

21 

Kernel 

m 

m 

m 

m 

22 

Read 

c 

o 

23 

Write 

c 

o 

24 

File  Access 

25 

Limited  File  Management 

0       fn  m 

m 

m 

m 

26 

Enhanced 

File  Management 

0       m  0 

m 

0 

m 

27 

Grouping 

m 

m 

m 

m 

28 

FADU  Locking 

29 

Recovery 

0 

o 

30 

Restart 

0 

o 

NOTE  -  M1.3(T)  indicates  Ml. 3  in  conjunction  with  a  Transfer  Profile  T1.3  or  T2.3,  This  table  lists  only  the  additional  functionality 
as  defined  by  Ml  ,3. 
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See  8.1 


M1.3(A) 

SERVICE  CLASSES 

FUNCTIONAL  UNITS 

Access 

D      Ml  .3(A) 

Management 
D      Ml  .3(A) 

31 

Kernel 

m  m 

32 

Read   

33 

Write   

34 

File  Access   

35 

Limited  File 

Management 

0  m 

m  m 

36 

Enhanced 

File  Management 

0  m 

0  m 

37 

Grouping 

m  m 

38 

FADU  Locking   

3» 

Recovery   

40 

Restart   

NOTE  -  M1.3(A)  indicates  M1.3  in  conjunction  with  the  Access  Profile  A1.3.  This  table  lists  only  the  additional  functionality  as 
defined  by  Ml. 3. 

A.I  2.6  Diagnostic  field  detail 

D 

T1.3,T2.3,  A1.3  M1.3 

Diagnostic  type 

m 

m  m 

2 

Error  identifier 

m 

m  m 

3 

Error  observer 

m 

m  m 

4 

Error  source 

m 

m  m 

5 

Suggested  delay 

0 

c                        i        see  8.5.2 

6 

Further  details 

0 

m  m 

For  values  of  the  'further  details'  term  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1 

(GO  and  Gl)  character  sets  is  required  (see  part  9  clause  13). 

! 

1, 
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A.12.7  Contents  type  detail 
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A.1 2.7.1  Contents  type  list  parameter 


See  part  9  10.2.1 


D 

PROHLES 

1  D 

1  H 

Maximum  number  of  elements 

document  type  specifications 
abstract  syntax  specifications 

o 

0 

o  m 
0  m 

A.1 2.7.2  Contents  type  parameter 

See  part  9  10.2.3 

D 

PROFILES 

REFERENCE 

document  type  specifications 

0 

m 

see  part  9  9.1 

abstract  syntax  /  constraint  set  pair 
speafications 

0 

1 

NOTE  -  The  detail  of  document  types  supported  is  contained  in  clause  A.  13. 


A.1 2.8  FTAM  Quality  of  service  details 


See  8.S.2 


A.1 2.9  Details  of  shared  ASE  information 

( Void ) 


A.1 2.10  Details  of  charging 


See  part  9  5.8  and  18.4 


Charging 

D 

PROFILES 

R 

Resource  identifier  term 

m 

m 

Charging  unit  term 

m 

m 

Charging  value  term 

m 

m 
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Filestore  password  detail 

D 

PROFILES 

OctetString 

0 

o 

GraphicString 

0 

o 

A.I  2.1 2  Create  password  detail 

See  part  9  16.3 

Create  password  detail 

D 

PRORLES 

OctetString 

o 

o 

GraphicString 

0 

o 

A.12.13  Concurrency  control 
A.1 2.13.1  Supported  values 

See  8.6.1 

T1.3 

not  required 

sliared 

exclusive 

no  access 

Action 

D 

T1.3 

D 

T1.3 

D 

T1.3 

D  T1.3 

Read 

0 

o 

0 

o 

0 

o 

0  o 

Insert 

0 

1 

0 

1 

0 

i 

o  1 

Replace 

0 

o 

0 

o 

0 

o 

o  o 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

Erase 

0 

1 

0 

1 

0 

I 

0  1 

Read  attrib 

0 

o 

0 

o 

0 

o 

0  o 

Change  attrib 

0 

i 

0 

i 

0 

1 

0  i 

Delete  file 

0 

o 

0 

o 

0 

o 

0  o 
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T2.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

T2.3 

D 

T2.3 

D 

T2.3 

D 

9 

rioaU 

0 

o 

o 

o 

o 

o 

0 

o 

10 

0 

o 

0 

o 

0 

o 

o 

o 

11 

0 

o 

0 

o 

o 

o 

0 

o 

12 

Extend 

0 

o 

o 

o 

0 

o 

0 

o 

13 

Erase 

0 

1 

0 

1 

0 

1 

0 

1 

14 

Read  attrib 

0 

o 

0 

o 

0 

o 

0 

o 

25 

Change  attrib 

0 

1 

0 

1 

0 

1 

0 

1 

16 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 

A1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D 

A1.3 

17 

Read 

0 

o 

0 

o 

0 

o 

0 

0 

18 

Insert 

0 

o 

0 

o 

0 

o 

0 

o 

1* 

Replace 

0 

o 

0 

o 

0 

o 

0 

o 

20 

Extend 

0 

o 

0 

o 

0 

o 

0 

e 

21 

Erase 

0 

o 

0 

0 

0 

o 

0 

o 

22 

Read  attrib 

0 

o 

0 

0 

0 

o 

0 

o 

23 

Change  attrib 

0 

1 

0 

1 

0 

1 

0 

1 

24 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 
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M1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

Ml. 3 

0 

Ml. 3 

D 

M1.3 

D  M1.3 

25 

Read 

o 

i 

0 

o 

1 

0  i 

26 

Insert 

0 

1 

c 

0 

1 

0  1 

27 

Replace 

0 

0 

0 

0  i 

28 

Extend 

0 

0 

0 

0  1 

20 

Erase 

0 

0 

0 

0  i 

30 

Read  attrib 

0 

o 

0 

0 

0 

o 

0  o 

31 

Change  attrib 

0 

o 

o 

o 

0 

o 

0  o 

32 

Delete  file 

0 

@ 

0 

® 

0 

o 

0  o 

A.1 2.13.2  Responder  Default  values 

— ________  .  _  , 

See  8.6.1,  part  9  clause  14 


A.1 2.1 4  FADU  Locking 


A1.3 

not  required 

FADU  Locking  Support  Values 
shared 

exclusive 

no  access 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

1 

Read 

0 

0 

0 

0 

0 

0 

0  o 

2 

Insert 

0 

o 

o 

o 

0 

0 

0  0 

3 

Replace 

0 

0 

0 

o 

0 

o 

0  o 

4 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

5 

Erase 

0 

o 

0 

o 

0 

o 

0  o 
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Initiator  ov«rrid« 

D 

PRORLES 
i 

Create  failure 

0 

o 

Select  old  file 

0 

o 

Delete  and  reaeate  with  old  attributes 

0 

o 

Delete  and  create  with  new  attributes 

0 

o 

NOTE  -  The  specification  of  the  role  of  responder  is  given  in  A.  10.5 


A.12.16  Requested  Access 

 See  part  9  clauM  IS 


Action 

D 

T1J 

T2J3 

A1.3 

Ml  .3 

Read 

0 

o 

o 

o 

Insert 

0 

1 

o 

o 

Replace 

0 

0 

o 

o 

Extend 

0 

o 

o 

o 

Erase 

0 

1 

1 

o 

Read  attribute 

0 

o 

e 

o 

m 

Change  attribute 

0 

1 

1 

1 

m 

Delete  file 

0 

o 

o 

o 

m 

A.12.17  Processing  mode 

Processing  mods 

D 

T1J 

T2.3 

A1.3 

Ml. 3 

Read 

o 

0 

o 

e 

Insert 

0 

1 

o 

o 

Replace 

© 

@ 

o 

o 

Extend 

0 

o 

o 

o 

Erase 

0 

1 

1 

o 
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A.12.18  Recovery  mode 

See  8.5.2 


Recovery  mode 

D 

T1.3,  T2.3,  A1.3 

None 

0 

m 

1 

At  start  of  transfer 

0 

m 

Any  active  checkpoint 

0 

o 

1 
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Section  6  :  Document  Type  Detail 


A.13  Document  types 

See  7.1 

Conformance  to  document  types  is  given  at  two  levels.  The  following  table  indicates  which  document  types  have 
some  level  of  support.  The  detail  of  that  level  of  support  is  stated  in  the  following  tables. 


Entry  number 

FTAM-1  D 

T1J 

T2.3  A1.3 

M1.3 

1 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  text  o 
(iso  standard  8571  document-type(5)  unstnjctured-text(1)) 

m 

m  m 

see  A.13.1 

1 

Entry  number 

FTAM-2  D 

T1.3 

T2.3  A1.3 

M1.3 

2 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  text  o 
{iso  standard  8571  document-type(5)  sequential-texl{2)} 

1 

m  m 

see  A,  13.2 

1 

Entry  number 

FTAM-3  D 

T1.3 

T2.3  A1.3 

M1.3 

3 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  binary  o 
{iso  standard  8571  document-type(5)  unstructured-binary(3)} 

m 

m  m 

see  A.13.3 

1 

Entry  number 

FTAM-4  D 

T1.3      T2.3      A1.3  M1.3 

4 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  binary  o 
{iso  standard  8571  document-type(5)  sequential-binary(4)} 

loci 

see  A.  13.4 

Entry  number 

NBS-6 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-6  FTAM  sequential  file 

1           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig{5) 

document-type(5)  sequenlial{6) } 

see  A.  13.5 

Entry  number 

NBS-7 

D 

T1.3      T2.3       A1.3    Ml. 3 

Object  descriptor 

NBS-7  FTAM  random  access  file 

i            o           o  1 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  random-file(7) ) 

see  A. 13. 6 
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Entry  number 

NBS-8 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-8  FTAM  indexed  file 

loot 

Object  identifier 

{ISO  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  indexed-file(8) } 

see  A.  13.7 

Entry  number 

NBS-9 

D 

T1.3 

T2.3  A1.3 

M1.3 

8 

Object  descriptor 
Object  identifier 

NBS-9  FTAM  file  directory  file 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  fiie-directory(9) ) 

o 

o  o 

see  part  9  16.3 

1 

Entry  number 

NBS-10 

D 

T1.3 

T2.3  A1.3 

M1.3 

9 

Object  descriptor 
Object  identifier 

NBS-10  FTAM  random  binary  access  file 
{iso  identified-organization  oiw(14)  ftamsig(5) 
document-type(5)  random-binary (10) } 

1 

o  o 

see  7.1 

1 

Entry  number 

NBS-11 

D 

T1.3 

T2.3  A1.3 

M1.3 

10 

Object  descriptor 
Object  identifier 

NBS-1 1  FTAM  indexed  file  with  unique  keys 
{iso  identified-organization  oiw(14)  ftamsig(5) 
document-type(5)  indexed-tile-with-unique-keys{  1 1 ) ) 

1 

o  o 

see  A.  13.8 

i 

I 


Entry  number 

NBS-1 2 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-12  NBS  FTAM  simple  text  file 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  simple-text-file(12) ) 

see  A.  13.9 
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Constraint  sets  and  FADU  identities  for  document  types 


For  the  constraint  set  /  FADU  identity  tables  the  following  notation  is  used: 


mandatory 


optional 
not  supported 
not  applicable 
excluded 


in  the  constraint  set  definition,  or  optiortal  in  the  constraint  set  definition  but  shall  be  impternented  by  implementations 

daiminfl  contomiance  to  the  Profile.  The  support  of  the  FAOU  identity  will  be  dependent  on  the  actions  which  have 

been  implemented. 

in  the  constraint  set  definition 

(outside  the  scope  of  this  ISP.  may  be  ignored) 

(rx>t  defined  in  the  constraint  set  definition) 

(disallowed  in  the  document  type  definition  or  in  FTAM  Phase  3) 


Implementation  Profile  Ti.3. 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-1 

m 

FTAM-3 

m 

NBS-9 

m 
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Implementation  Profile  T2.3  (see  7.2,  part  9  clause  10) 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-I 

m 

FTAM-3 

m 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

FTAM-2 

m 

m 

i 

1 

i 

i 

i 

1 

FTAM-4 

m 

m 

1 

1 

• 

i 

i 

1 

NBS-6 

m 

m 

i 

X 

X 

1 

X 

X 

NBS-12 

m 

m 

X 

X 

X 

X 

X 

X 

FTAM  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

0 

NBS-8 

m 

i 

1 

1 

i 

i 

i 

m 

1 

FTAM  ordered  flat  constr 
set  with  unique  names 

o 

o 

o 

o 

o 

o 

0 

NBS-11 

m 

i 

i 

i 

i 

m 

i 

NBS  ordered  fiat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

NBS-7 

m 

m 

m 

m 

i 

i 

I 

m 

NBS  random  access 
constraint  set 

o 

o 

o 

0 

( 

NBS-10 

m 

m 

m 

m 

1 

\ 

1 
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Implementation  Profile  A1. 3  (see  part  9  clause  10) 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAI«-1 

m 

FTAIW-3 

m 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

FTAM-2 

m 

m 

m 

i 

i 

m 

1 

1 

FTAM-4 

m 

m 

m 

1 

i 

m 

1 

i 

NBS^ 

m 

m 

m 

X 

X 

m 

X 

X 

NBS-12 

m 

m 

m 

X 

X 

m 

X 

X 

FTAM  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

o 

NBS-8 

m 

m 

i 

i 

m 

m 

m 

m 

i 

FTAM  ordered  flat  constr 
set  with  uni()ue  names 

o 

o 

o 

o 

o 

o 

o 

NBS-11 

m 

m 

m 

m 

m 

m 

1 

NBS  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

0 

NBS-7 

m 

m 

m 

m 

m 

m 

m 

m 

NBS  random  access 
constraint  set 

o 

o 

o 

0 

NBS-10 

m 

m 

m 

m 
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A.I 3.1  FTAWH    (See  7.1) 

A.13.1.1  Universal  class  number  parameter  (See  part  9  10.1) 


D 

T1.3,T2.3,  A1.3 

1 

Universal  class  number  parameter  supported 

0 

m 

2 

PrintableString   -           Universal  class  19 

o 

1 

3 

TeletexString     -           Universal  class  20 

0 

1 

4 

VideotexString    -           Universal  class  21 

0 

1 

5 

lASString                     Universal  class  22 

0 

m 

see  part  9  10.1.1-2 

6 

GraphicString     -           Universal  class  25 

m 

see  A.13.1.3 

7 

VisibleString      -           Universal  class  26 

0 

m 

8 

GeneralString     -           Universal  class  27 

0 

m 

see  A.13.1.4 

A.I  3.1 .2  String  length  parameter  and  string  significance  parameter  combinations 

D 

T1.3,T2.3,  A1.3 

1 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

m 

2 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

m 

3 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

4 

Unbounded  strings  and 
variable  length  strings 

0 

m 

5 

Unbounded  strings  and 
not  significant  strings 

0 

m 

A.1 3.1 .3  G  sets  supported 

G  sets  which  are  supported  in  FTAM-1  GraphicString.  

1      For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  Is  required, 
(see  part  9  10.1.1  and  10.1.3) 
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A.13.1.4  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  FTAM-1  GeneralString 


December  1992  (Stable) 


For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  is  required 
(see  part  9  10.1-3) 


A.13.2  FTAM-2      (see  7.1) 


A.13.2.1  Unh^ersal  class  number  parameter  (see  part  9  10.1) 


D 

T2.3,  A1.3 

Universal  class  number  parameter  supported 

0 

m 

PrintableString  - 

Universal  class  19 

0 

i 

TeletexString 

Universal  class  20 

0 

i 

VideotexString 

Universal  class  21 

o 

1 

lASString 

Universal  class  22 

0 

o 

see  part  9  10.1.1-2 

GraphicString 

Universal  class  25 

0 

m 

see  A.13.2.3 

VisibleString 

Universal  class  26 

0 

m 

GeneralString 

Universal  class  27 

0 

o 

see  A.13.2. 4 

A.13.2.2  String  length  parameter  and  string  significance  parameter  combinations 

D 

T2.3,  A1.3 

Maximum  string  length  parameter  and                      o  1 
variable  length  strings 

Maximum  string  length  parameter  and 
fixed  length  strings 

o 

i 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

0 

1 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.1 3.2.3  G  sets  supported 


December  1992  (Stable) 


G  sets  which  are  supported  in  FTAM-2  GraphicString. 


1      For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  pan  9  10.1.1  and  10.1.3) 


A.I  3.2.4  G  and  C  sets  supported 

G  arid  C  sets  which  are  supported  in  FTAM-2  GeneralString 


1     For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  Gl) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  is  required, 
(see  part  9  10.1.1-3) 


A.1 3.3  FTAM-3 

A.1 3.3.1  String  length  parameter  and  string  significance  parameter  combinations  (see  7.1) 


D          T1.3,  T2.3,  A1.3 

1 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

i 

2 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

3 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

4 

Unbounded  strings  and 
variable  length  strings 

0 

1 

5 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.13.4  FTAM-4  (see  7.1) 


A.1 3.4.1  String  length  parameter  and  string  significance  parameter  combinations 


D 

T2.3.  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

o 

1 

Maximum  siring  length  parameter  and 
fixed  length  strings 

0 

1 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

0 

1 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.13.5  NBS-6 


December  1992  (Stable) 


See  part  9  tables  2,  3 

A.1 3.5.1  ParameterO 


D 

T2.3,  A1.3 

ParameterO  supported 

m 

Universal-time 

Universal  class  23 

- 

m 

Generalized-time 

Universal  class  24 

- 

m 

boolean 

Universal  class  1 

- 

m 

null 

Universal  class  5 

- 

m  « 

|Jafl  9    IV.  1^ 

D 

T2.3,  A1.3 

Parameter  1  supported 

m 

integer 

Universal  class  2 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

GraphicString 

Universal  class  25 

m 

GeneralString 

Universal  class  27 

m 

OcletString 

Universal  class  4 

m 

A.1 3.5.3  Parameter2 

D 

T2.3,  A1.3 

Parameter2  supported 

o 
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A.13.6  NBS-7 


December  1992  (Stable) 


A.1 3.6.1  ParameterO 

See  part  9  tables  2,  3 

D 

T2.3,  A1.3 

1 

ParameterO  supported 

m 

2 

Universal-time 

Universal  class  23 

m 

3 

Generalized-time 

Universal  class  24 

m 

4 

boolean 

Universal  class  1 

m 

S 

null 

Universal  class  5 

m 

A.1 3.6.2  Parameteii  (sa 

fV  Will  t  0    I  V*  1  1 

D 

T2.3,  A1.3 

1 

Parameterl  supported 

• 

m 

2 

integer 

Universal  class  2 

m 

3 

bit 

Universal  class  3 

m 

4 

IA5 

Universal  class  22 

m 

S 

GraphicString 

Universal  class  25 

m 

6 

GeneralString 

Universal  class  27 

m 

7 

OctetString 

Universal  class  4 

m 

A.1 3.6.3  Parameter2 


D 

T2.3,  A1.3 

Parameter2  supported 

o 
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A.  13.7  NBS-8 
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See  part  9  tables  2,  3 

A.I  3.7.1  ParameterO 


Data  Types 

D        T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

ParameterO  supported 

m 

m 

Universal-time 

Universal  class  23 

m 

m 

Generalized-lime 

Universal  class  24 

m 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

m 

A.I  3.7.2  Parameterl 

(see  part  9  10.1) 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

Parameter  1  supported                                                                  m                   -  m 

integer 

Universal  class  2 

m 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

m 

GraphicString 

Universal  class  25 

m 

m 

GeneralString 

Universal  class  27 

m 

m 

OctetString 

Universal  class  4 

m 

m 

A.1 3.7.3  Parameter2 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D        T2.3,  A1.3 

Parameter2  supported 

o 

o 
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A.13.8  NBS-11 


December  1992  (Stable) 


Sea  part  9  tables  2,  3 

A.1 3.8.1  ParameterO 


Data  Types 
D      T2.3,  A1.3 

Key  Type 

D  T2.3,A1.3 

ParameterO  supported 

m 

m 

Universal-time 

Universal  dass  23 

m 

m 

Generalized-time 

Universal  class  24 

m 

m 

boolean 

Universal  dass  1 

m 

null 

Universal  dass  5 

m 

A.1 3.8.2  Parameten 

(see  part  9  10.1) 

Data  Types 

D        T2.3,  A1.3 

D  T2.3,A1.3 

Parameterl  supported 

m 

m 

integer 

Universal  dass  2 

m 

m 

bit 

Universal  dass  3 

m 

IA5 

Universal  dass  22 

m 

m 

GraphicSthng 

Universal  dass  25 

m 

m 

GeneralString 

Universal  dass  27 

m 

m 

OctetStnng 

Universal  dass  4 

m 

m 

A.1 3.8.3  Parameter2 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D        T2.3,  A1.3 

Parameter2  supported 

o 

o 

I 
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A.13.9  NBS-12    (see  7.1) 

A.13.9.1  Untvarsal  class  numbor  parametor  (sas  part  9  10.1) 


D 

T2.3,  A1.3 

Universal  dats  number  parameter  supported 

- 

m 

PrintableString 

Universal  class  19 

1 

TeletexString 

Universal  class  20 

1 

VideotexString 

Universal  class  21 

1 

lASSthng 

Universal  class  22 

m 

GraphicString 

Universal  class  25 

m 

see  A.  13.9.5 

VisibleString 

Universal  class  26 

m 

GeneralString 

Universal  class  27 

m 

see  A.13.9.6 

A.I  3.9.2  String  Isngth  parameter 

D 

T2.3,  A1.3 

Maximum  string  length  parameter  supported 

m 

A.I  3.9.3  String  significance  parameter 


D 

T2.3,  A1.3 

String  significance  parameter  supported 

m 

see  7. 1  table  3(c) 

Variable  length  strings  supported 

m 

Fixed  length  strings  supported 

m 

A.I  3.9.4  Character  set  parameter 

D 

T2-3,  A1.3 

Character  set  parameter  supported 

m 

see  7.1  table  3(c) 
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A.1 3.9.5  G  sets  supported 

G  sets  which  are  supported  in  NBS-12  Graph icString.  

For  valuea  of  GraphicString  only  ttie  support  of  character  atrings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  aeta  la  required, 
(see  part  9  10.1.1  and  10.1.3) 


A.1 3.9.6  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  In  NBS-12  GeneralString.  

For  valuea  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  aet  and  ISO  646  IRV  (CO)  control  character  sets  is  required, 
(see  part  9  10.1.1-3) 


-  END  OF  FTAM  PHASE  3  PROFILES  REQUIREMENTS  LIST  - 
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December  19S2  liable) 


Annex  B  (normative) 


Register  of  FTAM  Objects 
B.I  Introduction 

The  objects  defined  in  B.2.1  and  B.2.2  will  be  renK>ved  from  this  document  after  ISO/IEC  ISP  10607-2 
and  ISO/IEC  ISP  10607-2/Amd.1  are  published.  During  the  period  between  publishing  the  ISP  and  the 
removal  of  the  definitions  from  this  document,  the  definitions  in  the  ISP  wNI  take  precedence  over  this 
document 

When  the  object  definitions  are  removed,  clauses  B.2.1  and  B.2.2  wHI  be  changed  to  point  to  the  ISP. 
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fi^  Index  Qf  QIW  FTAM  Objects 

P-2.1    FTAM  Phasa  2  Definad  Qb|ects 


December  1991  (Stable) 


Object  Idantifier  Prefix  :    nist-adhoc  ::-  {iso(1)  identified-organization(3)  iod(9999)  organization-code(1 }} 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 

Registration 

Rafarance  to 

Definition 

NBS-6 

NBS-6  FTAM 
sequential  file 

{nist-adhoc 
document-type(5) 
sequential(6) } 

Dec  15.  '89 

Withdrawn 
March  16,  '90 

Stable  Aqreements 

Vers.  4,  td.  1 .  December  *90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.1 

NBS-7 

NBS-7  FTAM  random 
access  file 

{nist-adhoc 
document -type(5) 
random-file(7) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Aqreements 

Vers.  4,  Ed.  1 .  December  '90 

NIST  SP  500-183 

■  11^^  ■                www     t  WW 

part  9,  annex  A  clause  A.2 

NBS-8 

NBS-8  FTAM 
indexed  file 

{nist-adhoc 
document-type(S) 
tndexed-file(8) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 .  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.3 

NBS-9 

NBS-9  FTAM  file 
directory  file 

{nist-adhoc 
document-type(5) 
file-directory(9) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-1 83 

part  9,  annex  A  clause  A.4 

NBS  ordered  flat 
constraint  set 

{nist-adhoc 

constraint-set(4) 

nbs-ordered-flat(l)} 

Dec  15,  '89 
Withdrawn 

IVIai  vn  1 Q,  9U 

Stable  Aqreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9,  annex  B  clause  B.I 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-adhoc 
abstract-syntax  (2) 
nbs-asl(l) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 

Vers.  4.  Ed.  1,  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.I 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-adhoc 
abstract-syntax(2) 
nbs-as2(2) } 

Dec  15,  '89 

Withdrawn 
March  16.  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9,  annex  C  clause  C.2 

AP-Title 

(nist-adhoc 
ftam-nil-ap-title(7) } 

Dec  15.  '89 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  5  1^1.1.1 
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Object  Identifier  Prefix  :    nist-olw-ftam  :>  {iso(1)  identified-organization(3)  oiw(14)  ftamsig(5)} 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-6 

NBS-6  FTAM 
sequential  file 

{nist-oiw-ftam 
document-typ6(5) 
sequentiai(6) } 

March  16.  '90 

Stable  Agreements 

Vers.  4,  bd.  1 .  December  '90 

NIST  SP  500-183 

part  9.  annex  A  clause  A.5 

NBS-7 

NBS-7  FTAM  random 
access  file 

{nist-oiw-ftam 
document-type(5) 
random-file(7) ) 

March  16.  '90 

Stable  Agreements 

Vers.  4,  Ed.  1.  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.6 

NBS-8 

NBS-8  FTAM 
indexed  file 

{nist-oiw-ftam 
document-type(5) 
indexed-file(8) } 

March  16.  '90 

Stable  Agreements 

Vers.  4,  bd.  1.  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.7 

NBS-9 

NBS-9  FTAM  file 
directory  file 

{nist-oiw-ftam 
document-type(5) 
file-directory(9) } 

March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.8 

NBS  ordered  flat 
constraint  set 

{nist-oiw-ftam 
constraint-set(4) 
nbs-ordered-flat(1 ) } 

March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 .  December  '90 

NIST  SP  500-183 

part  9,  annex  B  clause  B.2 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-asl(l) } 

March  16.  '90 

Stable  Agreements 

Vers.  4,  td.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.3 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-as2(2) ) 

March  16,  '90 

Stable  Aareements 

Vers.  4,  Ed.  1 .  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.4 
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FTAM  Phaaa  3  Defined  Qblocta 


Object  Identifier  Prefix  :    nist-olw-ftam  :«  iso(1)  identified-organization(3)  oiw(14)  ftamsig(5) 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-10 

NBS-10  random 
binary  access  file 

{nist-oiw-ftam 
document-type(S) 

iciiiuuiii*wiiiaiy^  \v)  r 

Dec  15.  '89 

Stable  Agreements 

Vers.  4,  Ed.  1 .  December  '90 

Nib  1  or  oUU- 1  UJ 

part  10,  annex  C  clause  C.I 

NBS-11 

NBS-11  FTAM  indexed 
file  with  unique  i^eys 

(nist-oiw-ftam 
document-type(5) 

inuaAvU*llla*VVIin*UniCfUB* 

keys(ll)} 

Dec  15.  '89 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

Nib  1  or  300- loJ 

part  10.  annex  C  clause  C.2 

NBS*12 

NBS-12  FTAM 
simple  text  file 

{nist-oiw-ftam 
document-type(5) 
simpie-iexi-iiie^  1 

Dec  15.  '89 

Stable  Agreements 

Vers.  4.  Ed.  1.  December  '90 

NIo  1  or  bOO-ioJ 

part  10.  annex  C  clause  C.3 

NBS  Random  Access 

{nist-oiw-ftam 
constraint-set(4) 
nbs-random-access(2) } 

Dec  15.  '89 

Stable  Agreements 

Vers.  4.  Ed.  1 ,  December  '90 

NIo  1  or  300- 1  oJ 

part  10.  annex  D  clause  D.I 

NBS-AS3 

NBS  random  access 
node  name  abstract 
syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-node-name(3) } 

Dec  15.  '89 

Stable  Agreements 

Vers.  4,  td.  1 ,  December  '90 

NISTSP  500-183 

part  10,  annex  E  clause  E.1 

NBS-AS4 

NBS  random  binary 
access  file 
abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-random-binary(4) } 

Dec  15.  '89 

Stable  Agreements 

Vers.  4,  Ed.  1 .  December  '90 

NIST  SP  500-183 

part  10,  annex  E  clause  E.2 

NBS-AS5 

NBS  simple  text 
abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-simpie-text(5) } 

Dec  15.  '89 

Stable  Agreements 

Vers.  4.  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  1 0.  annex  E  clause  E.3 

1 
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Decembor  1992  (Stable) 


Annex  C  (normative)   

Document  Types 

C.I     NBS-10  Random  Binary  Access  File 
C.1.1       Entry  Number:  NBS-10 
C.I  .2      Information  objects 
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Table  4  -  Information  objecU  in  NBS-10 

document  type  name 

{iso  identified-organizatton  oiw(14)  ftam8ig(5)  document-type(5) 
'NBS-10  FTAM  random  binary  access  file* 

a)  name  of  asnamel 

name  of  asname2 
c)  name  of  a8nanr>e3 

{iso  identified-organization  o(w(14)  ftam8ig(5)  ab8tract-syntax(2) 
nb8-rarKk>m-binary(4) } 

'NBS  random  binary  access  file  atistract  syntax*  {iso  standard 
8571  ahstract-svntay^^^  f^am>fariu/9H 
•RAM  FADU' 

{iso  identified-organization  0(w(14)  ftamsig(5) 

abstract-syntax(2)  nbs-node-name(3)} 

'NBS  random  access  node  name  abstract  syntax* 

1  transfer  syntax  names: 

{joint-iso-cdtt  asn1(1)  basic-encoding(1)> 
'Basic  encoding  of  a  single  ASN.1  type' 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
'FTAM  hierarchical  file  moder 

constraint  set 

{iso  identified-organization  oiw(14)  ftamsig(5) 
constraint-set(4)  nbs-randonvaccess(2)}- 
'NBS  random  access  constraint  sef 

File  contents: 

Datatypel  ::=  OCTET  STRING 

Datatype2  Node-Name 
-The  type  to  be  used  for  Node-Name  is  defined  in  ISO  8571 -FAOU 
-The  only  Choice  for  Node-Name  is  user-coded 

Datatypes  ::=  NBS-Node-Name 
\          -As  defined  by  the  NBS  Random  Access  Node-Name  Abstract  Syntax 

C.1 .3      Scope  and  field  of  application 

'j  This  docun>ent  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
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C.I  .4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management 


C.I. 5  Definitions 

This  definition  makes  use  of  tlie  ternis  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


C.I. 6  Abbreviations 

FTAM  FHe  Transfer,  Access  and  Management 


C.I. 7      Document  semantics 

The  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  contains  precisely  one 
data  unit  which  consists  of  precisely  one  data  element.  The  data  element  Is  made  up  of  one  octet.  The 
order  of  each  of  these  elements  is  significant.  The  semantics  of  the  data  elements  Is  not  specified  by 
this  document  type. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  NBS  random  access  constraint  set.  The  definition  for  FTAM  hierarchical  file  model 
appears  in  8571-2. 

There  are  no  size  or  length  limitations  Imposed  by  this  definition. 


C.1.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  series  of  octets. 


C.I  .9      Definition  of  transfer 
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C.I  .9.1        Datatype  definition 

The  presentation  data  value  used  for  transfer  is  an  ASN.1  OCTET  STRING. 

Datatype2  is  used  to  specify  the  FADU-ldentity  of  "name-list"  in  the  FTAM  PDUs  specifying  FADU- 
Identity.  where  "name-list"  is  defined  as  a  SEQUENCE  of  EXTERNAL  The  EXTERNAL  is  defined  as 
Node-Name  in  the  FTAM  FADU  abstract  syntax.  The  use  of  Datatype2  is  defined  in  "NBS  random 
access  constraint  set." 
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Datatypes  specifies  tiie  "user-coded"  form  of  the  Node-Name  in  tlie  FTAM  FADU  abstract  syntax,  where 
"user-coded"  is  defined  as  an  EXTERNAL  That  EXTERNAL  is  defined  by  Datatypes.  The  use  of 
Datatypes  is  defined  in  "NBS  random  access  constraint  set." 


The  document  is  transmitted  as  a  series  of  presentation  data  vaiues.  Each  presentation  data  value  shall 
consist  of  the  "data"  from  one  or  more  FADUs  concatenated  togetlier.  The  result  is  one  value  of  the 
ASN.1  data  type  OCTET  STRING.  The  "fadu-count"  field  supplied  in  the  Node-Name  specifies  the 
number  of  FADUs  to  transfer  during  a  Read  operation.  The  requested  FADUs  may  be  transferred  as  one  i 
or  more  presentation  data  values. 

i 

All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to  support  the  abstract  , 
syntax  name  "asnamel"  declared  in  table  4. 


NOTE  -  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  i; 
used,  when  the  atx>ve  permits  a  choice.  , 

Boundaries  between  P-DATA  primitives  and  between  presentation  data  values  are  chosen  locally  by  the 
sending  entity  at  the  time  of  transmission.  The  tx)undaries  are  not  preserved  when  the  file  Is  stored  and  I 
they  carry  no  semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall 
accept  a  document  with  any  of  the  permitted  transfer  options. 


The  sequence  of  presentation  data  values  is  the  same  as  the  sequence  of  Data  Units  within  the  file. 
C.1 .1 0     Transfer  syntax 

An  implementation  supporting  these  document  types  shall  support  the  transfer  syntax  generation  rules 
named  in  table  4  for  all  presentation  data  values  transferred. 

Implementations  may  optionally  support  other  transfer  syntaxes. 
C.I  .11     ASE  Specific  Specifications 
C.1.11.1  Simplification 

The  document  type  NBS-10  may  be  simplified  to  the  document  type  FTAM-S.  The  resultant  document 
contains  the  same  sequence  of  data  values  as  would  result  from  accessing  the  file  as  an  NBS-10  file. 


C.I  .9.2 


Presentation  data  values 


0«1  adsd 


Sequence  of  presentation  data  values 
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C.I  .1 1 .2      The  READ  operation 

A  READ  operation  may  be  applied  to  a  range  of  FADUs  via  the  FADU-ldentity  of  "NodeSeq .'  The 
"starting-fadu"  part  of  the  node  name  specifies  the  node  number  of  the  first  FADU;  the  "fadu-count" 
specifies  the  number  of  consecutive  FADUs  to  be  transferred. 

A  READ  operation  appiied  to  a  range  of  FADUs  that  spans  beyond  the  end  of  file  Is  valid.  All  available 
data  in  the  range  is  transferred.  An  informative  diagnostic  (5005)  is  retumed  on  the  F-Data-End  request 
indicating  that  the  end  of  file  was  reached  and  a  portion  of  the  request  was  satisfied. 


C.I  .1 1 .3      The  REPLACE  operation 

When  the  REPI-ACE  operation  is  applied  to  the  root  FADU  of  an  NBS-10  document,  the  transferred  data 
shall  be  any  NBS-10  document. 

The  REPLACE  operation  applied  to  a  FADU-ldentity  of  "node  numt)er"  is  used  to  replace  a  series  of 
FADUs,  starting  at  the  specified  position  in  the  file,  by  the  new  FADUs  being  transferred.  The  number  of 
replaced  FADUs  is  determined  by  the  number  of  transferred  FADUs. 

If  the  replacement  spans  beyond  the  end  of  the  existing  file,  then  the  additional  FADUs  are  inserted  at 
the  end  of  the  fHe. 


C.1 .1 1 .4      The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the  transfen-ed  data  shall  be  a  series  of  FADUs 
which  would  be  generated  by  reading  any  NBS-10  document  type  in  access  context  UA. 


C.2 


NBS-11  Indexed  File  With  Unique  Keys 


C.2.1 


Entry  Number:  NBS-11 


C.2.2 


Information  objects 
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Tabtt  5  -  Infofmatlon  objectt  In  NBS-11 


document  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

indexed-file-wittvunique-keys(1 1)} 

'NBS-11  FTAM  indexed  file  witfi  unique  keys' 

abstract  syntax  names: 

a)  name  for  asnamel 

{iso  klentifiad-organization  oiw(14)  ftamsig(5)  abstract  syntax(2) 

nb8-as1(1)} 

'NBS  abstract  syntax  AS1' 

b)  name  for  asname2 

{iso  standard  8571  abstract-syntax(2)  ftam-feidu(2)} 

'FTAM  FADU* 

transfer  syntax  names: 

{joint-iso-cdtt  a8n1(1)  basi&encoding(1)} 

'Basic  Encoding  of  a  single  ASN.1  type' 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE  { 

DataTypes, 

KeyType, 

KeyPosition  } 

DataTypes  ::»  SEQUENCE  OF  CHOICE  { 

ParameteiO, 

Parameterl, 

Parameter2  } 

KeyType    ::=  CHOICE  { 

ParametetO, 

Parameterl , 

Parameter2  } 

-  ParameterO,  Parameterl,  Parameter2,  as 

-  defined  for  the  document  types  NBS-6, 

-  NBS-7,  NBS-8 

KeyPosition::  INTEGER 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(1)> 

'FTAM  hierarchical  file  model' 

constraint  set 

{iso  standard  8571  constraint-8et(4) 

ordered-f)at-unlque-names(4)  > 

'FTAM  ordered  flat  constraint  set  with  unique  names* 

file  contents: 

Datatypel  ::=  PrimType 

~  as  defined  in  NBS-ASI 

Datatype2  ::=  CHOICE  { 

Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element, 

Exit-Subtree-Data-Element  } 

Datatypes  ::=  Prim  Type  -  as  defined  by  the  NBS  abstract  syntax  AS1 
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C.2.3      Scope  and  field  of  application 

I     The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  using  FTAM. 
^  NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


C.2.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management 


C.2.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


C.2.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


f  C.2.7      Document  semantics 

I    The  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  consists  of  precisely 
one  data  unit  which  consists  of  zero,  one,  or  more  data  elements.  The  order  of  each  of  these  elements 
1    is  significant. 

The  document  structure  tal<es  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  FTAM  ordered  flat  constraint  set  with  unique  names  (see  table  5).  These  definitions 
appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of  the  ordered  flat  constraint  set  with 
I    unique  names: 

The  FADU  identity  "node  number"  is  not  required  for  conformant  implementations; 
[  The  identities  "next"  and  "previous"  are  allowed  for  all  FADUs. 

j    Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types  defined  in  part  9  Annex  C,  NBS 
\    abstract  syntax  ASl.  Each  data  unit  contains  the  same  data  element  types  in  the  same  order  as  all 
I    other  data  units.  These  types  and  their  respective  maximum  lengths  are  defined  by  the  <DataTypes> 
parameter. 
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For  Datatypel  and  Datatype3,  the  string-length  field  of  Parameterl  specifies  the  length  of  the  value  in 
octets  for  the  INTEGER.  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the 
string-tength  Indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including 
any  escape  sequences  or  overfiead  from  the  character  encoding. 

For  floating  point  numt>ers.  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectiveiy.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating 
point  numbers. 

Each  data  unit  in  the  fNe  has  a  l(ey  associated  with  it.  which  is  the  user-coded  form  of  Node-Name.  The 
l(ey  of  each  data  unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a  single 
data  element  from  the  set  of  primitive  data  types  defined  in  part  9  Annex  C,  C.3  of  NIST  SP  500-183. 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType>  parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which  an  implementatton  must  accept 
as  a  key  value  are  given  in  the  following  table  6. 


Table  6  -  Datatypes  for  keys 


Minimum 

Order 

1  Key  Type 

Range 

(octets) 

ASN.1  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.1  lASString 

(1-16) 

lexical  order 

ASN.1  GraphicString       ASN.1  GeneralString 

(1-16) 

lexical  order 

ASN.1  OCTET  STRING 

(1-16) 

lexical  order 

ASN.1  GeneraiizedTime 

(1-16) 

increasing  value 

ASN.1  UniversalTime 

increasing  time  value 

NBS-AS1  Fk>aHngPoirTtNumt)er 

increasing  time  value 

increasing  numeric  value 

The  posit kxi  of  the  key  in  the  data  unit  is  specified  by  the  <KeyPositk}n>  parameter. 
KeyPositkxi  =  0  implies  the  key  Is  not  part  of  the  data 
KeyPositkxi  >  0  specifies  the  actual  data  element  in  the  data  unit. 


C.2.8      Abstract  syntactic  structure 

The  abstract  syntactto  structure  of  the  document  is  a  hierarchk^ly  structured  file  as  defined  in  the 
ASN.1  module  IS08571-FADU  in  ISO  8571,  in  whteh  each  of  the  file  access  data  units  has  the  abstract 
syntactk:  structure  of  NBS-ASI  as  defined  by  the  parameters. 
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C.2.9 


Definition  of  transfer 


C.2.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of 

a)  Datatypel  defined  in  tat>le  5,  where  the  PrimType  In  the  datatype  Is  given  by  the  NBS-ASi 
definition;  or 

b)  Datatype2  defined  In  table  5,  which  Is  the  ASN.1  datatype  declared  as  "Data-Elemenf  in  the 
ASN.1  module  IS08571-FADU:  or 

c)  Datatypes,  defined  in  Table  5,  which  specifies  the  user-coded  fonri  of  the  Node-Name  In  the 
FTAM  FADU  abstract  syntax,  where  user-coded  Is  defined  as  EXTERNAL 


C.2.9.2       Presentation  data  values 

The  document  Is  transferred  as  a  series  of  presentation  data  values,  each  of  which  Is 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  canying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  In  the  same  (but  any)  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2.";  or 

c)  a  value  of  "Datatypes"  carrying  a  Key.  All  values  are  transmitted  in  the  same  (but  any) 
presentation  context  established  to  support  the  abstract  syntax  name  "asnamel ". 


1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  t>e  used. 


2  Any  document  type  defined  in  this  entry  either  mal<es  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 


Boundaries  between  presentation  data  values  In  the  same  presentation  context,  and  boundaries  t>etween 
i    P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
1   semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document 

with  any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 


The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of 
types  a)  and  b)  Is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the 


NOTES 


where  the  above  permits  a  choice. 


C.2.9.3 


Sequence  of  presentation  data  values 
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hierarchica!  structure,  when  flattened  according  to  the  definition  of  the  hierarchical  f9e  model  in  ISO 
8571-2. 


C.2.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules 
named  in  tat)le  5  for  ail  presentation  data  values  transfen'ed.  Implementatton  may  optionally  support 
other  named  transfer  syntaxes. 


C.2.11     ASE  Specific  Specifications 


C.2.11.1  Simplification 

This  simplification  loses  information. 

The  document  type  NBS-1 1  may  be  accessed  as  a  document  type  RAM-3  (allowed  only  when  reading 
the  file)  by  specifying  document  type  RAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >, 
and  limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is  unpredictat)le.  it  will  usually  corresporKi  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-1 1  can  l^e  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading 
the  file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  In  the  <  contents 
type>  parameter  on  the  <F-OPEN  request  >.  The  traversal  order  of  the  FADUs  must  be  maintained. 

NOTE  -  The  traversal  order  is  as  reading  the  file  as  NBS-1 1  in  key  order. 

A  document  of  type  NBS-1 1  may  t>e  accessed  as  a  document  of  type  NBS-8  (allowed  only  when  reading 
the  file)  by  specifying  document  type  NBS-8  in  the  <  contents  type>  parameter  in  the  <F-OPEN 
REQUEST  >. 


C.2.11 .2      Access  context  selection 

A  document  of  type  NBS-1 1  may  t>e  accessed  in  any  one  of  the  access  contexts  defined  in  the  FTAM 
ordered  flat  constraint  set  with  unique  names.  The  presentation  data  units  transferred  in  each  case  are 
those  derived  from  the  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


C.2.1 1 .3      The  INSERT  operation 

When  the  <  INSERT  >  operation  is  applied,  the  transferred  material  shall  be  the  series  of  FADUs  which 
would  be  generated  by  reading  any  NBS-1 1  document  with  the  same  parameter  values  in  access 
context  FA. 
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A  transferred  FADU  whose  name  duplicates  that  of  an  already  existing  FADU  will  cause  the  <  INSERT  > 
operation  to  fal.  The  falure  shall  be  signalled  by  issuing  an  F-CANCEL  Request  with  a  corresponding 
diagnostic. 


C.2.1 1 .4      The  EXTEND  operation 

This  operation  is  wduded  for  use  with  this  docunient  type. 


C^.1 1 .5      The  REPLACE  operation 

When  the  <  REPLACE  >  operation  is  applied  with  FADU  identity  'Isegln.'  a  transferred  FADU  whose  nanie 
duplicates  that  of  a  previoiisly  transfen-ed  FADU  wll  cause  the  <  REPLACE  >  operation  to  faH.  The 
feiHure  shall  be  signalled  by  Issuing  an  F-CANCEL  Request  with  a  corresponding  diagnostic. 
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C.3     NBS-12  Simple  Text  File  Document  Type 
C.3.1       Entry  Number:  NBS-12 
C.3.2      Information  objects 


Table  7  -  Information  objects  In  NBS-12 


document  type  names 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

simple-text-file(12)} 

'NBS-12  FTAM  simple  text  file' 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 

nbs-simple-text(5)} 

'NBS  simple  text  abstract  syntax' 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 

■FTAM  FADU' 

transfer  syntax  names: 

{joint-iso-ccitt  asnl  (1)  basic-encoding  (1)} 
'Basic  Encoding  of  a  single  ASN.1  type* 

Parameter  Syntax 
PARAMETERS  ::=  SEQUENCE  { 

universal-dass-number  [0]  IMPUCIT  INTEGER, 
1          maximum-string-length  [1]  IMPUCIT  INTEGER, 
1          string-significance  [2]  IMPUCIT  INTEGER 
1             {variable  (0),  fixed  (1)}, 

character-set  [3]  IMPUCIT  OCTET  STRING  OPTIONAL  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
'FTAM  hierarchical  file  model' 

constraint  set 

{iso  standard  8571  constraint-set(4)  sequential  flat(2)} 
'FTAM  sequential  fiat  constraint  sef 

File  contents 
1            Datatypel  ::=  NBS-Text 

-as  defined  in  the  NBS  Simple  Text 
-Abstract  Syntax  registration  entry 

Datatype2  ::  =  Node-Descriptor-Data-Element 
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C.3.3      Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  and  for  transfer  and  access  by  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 

C.3.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  •  File  Transfer, 
Access  and  Management 

ISO  8824,  Infonvation  Processing  Systems  -  Open  Systems  Interconnection-Specttlcation  d 
Abstract  Syntax  Notation  1  (ASN.1). 

ISO  8825,  Information  Processing  Systems  -  Open  Systems  Interconnectlorh-Basic  Encoding 
Rules  for  Abstract  Syntax  Notation  One  (ASN.  1). 

ISO  6429,  Information  Processing  -  ISO  7-bit  and  8-bit  coded  character  sets-Additional  control 
functions  for  character  Imaging  devices. 

C.3.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1.  In  addition,  it  makes  use  of  the  terms  character  string,  graphics  character,  and  format  effector 
as  defined  in  document  type  registration  entry  "FTAM-2"  in  ISO  8571-2. 

C.3.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

C.3.7      Document  semantics 

This  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  consists  of  predseiy 
one  data  unit  whteh  consists  of  precisely  one  character  string.  The  order  of  each  of  these  elements  is 
signifteant.  The  semantics  of  the  character  strings  is  not  specified  by  this  document  type. 

The  document  structure  takes  any  of  the  fonns  allowed  by  the  FTAM  hierarchical  file  nxxiei  as 
constrained  by  the  sequential  fiat  constraint  set.  These  definitions  appear  in  ISO  8571-2.  As  additkxiai 
constraints,  FADU  kJentity  will  be  limited  to  the  following  values: 

a)  "begin"  "and  "end"  when  using  the  Transfer  or  Transfer  and  Management  servtee  classes: 

b)  "begin,"  "end,"  "first,"  and  "next"  when  using  the  Access  sen^e  dass. 
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Each  character  string  consists  of  characters  from  the  character  set  defined  by  the  ASN.1  (ISO  8824) 
character  set  type  whose  universal  class  numiser  is  given  by  the  "universal-class-number"  parameter  and 
by  the  escape  sequences  contained  in  the  optional  "character-set"  parameter.  If  the  character  set  type 
allows  explicit  escape  sequences,  the  "character-set"  parameter,  if  present,  contains  escape  sequences 
which  designate  and  invoke  specific  character  sets.  If  the  "character-set"  parameter  is  not  present, 
character  sets  are  assumed  to  be  designated  and  invoked  as  specified  in  table  2  in  ISO  8825.  Character 
strings  shall  not  contain  escape  sequences. 

There  are  no  size  or  length  limitations  imposed  by  this  definition,  except  those  specified  here.  Each 
character  string  is  of  a  length  determined  by  the  number  of  characters  given  by  the  "maximum-string- 
length"  parameter. 

NOTE  -  The  length  restriction  refers  to  the  numt>er  of  characters  from  the  applicable  character  set,  not  to 
the  number  of  octets  in  the  encoding,  nor  to  the  line  length  in  any  rendition  of  the  document,  where  these 
are  different. 


The  exact  signiftoance  of  the  character  strings  is  determined  by  the  "string-significance"  parameter.  If  its 
value  is  "variable,"  the  length  of  the  character  strings  is  less  than  or  equal  to  the  length  given.  If  the 
value  is  "fixed,"  the  length  of  each  character  string  is  exactly  equal  to  the  length  given. 

If  the  document  is  interpreted  on  a  character  imaging  device  (outskJe  the  scope  of  ISO  8571),  the 
interpretation  depends  on  the  cliaracter  set  in  use. 

a)  If  the  character  set  contains  format  effectors,  they  shall  be  interpreted  as  defined  in  ISO 
6429;  end  of  string  and  end  of  file  access  data  unit  are  given  no  formatting  significance,  and  do 
not  contribute  to  the  document  semantics; 

b)  If  the  character  set  does  not  contain  format  effectors,  the  end  of  each  character  string  is 
interpreted  as  implying  carriage  return  and  line  feed  formatting  actions  in  any  rendition.  The  end 
of  file  access  data  unit  is  given  no  formatting  significance  beyond  that  attached  to  the  end  of  the 
string  in  it. 


C.3.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the 
ASN.1  modules  IS08571-FADU  and  ISO  8571 -CONTENTS  in  ISO  8571,  in  which  each  of  the  file  contents 
data  elements  has  the  abstract  syntactic  structure  of  "NBS-Text." 
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C.3.9      Deflnition  of  transfer 


C.3.9.1       Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  7.  the  ASN.1  datatype  declared  as  'NBS-Text"  In  the  NBS  simple 
text  abstract  syntax  definition.  The  choice  in  "NBS-Text"  is  detemiined  by  the  universal-dass- 
number  parameter;  or 

b)  Datatype2  defined  in  table  7,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  ISO  8571 -FADU. 


C.3.9.2       Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  character  strings  of  the 
document.  Each  character  shall  be  transmitted  using  one  of  the  character  sets  identified  by  the 
universal-dass-number  parameter.  Ail  values  are  transmitted  in  the  same  (but  any)  presentation 
context  established  to  support  the  abstract  syntax  name  "asnamel"  declared  in  table  7;  or 

b)  one  value  of  the  ASN.1  datatype  "Datatype2."  All  values  are  transmitted  in  the  same  (but 
any)  presentation  context  estat)lished  to  support  the  abstract  syntax  name  "asname2'  declared 
In  table  7. 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used, 
where  ttie  at)ove  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  mal<es  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  P-DATA  primitives  are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,  and  carry  no  semantics  of  the  document  type.  Receivers  which  support  this  document 
type  shall  accept  a  document  with  any  of  the  permitted  transfer  options. 
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C.3.9.3       Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of 
types  a)  and  b)  Is  the  same  as  the  sequence  of  character  strings  within  a  Data  Unit,  and  Data  Units  in 
the  hierarchical  structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 


C.3.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules 
named  in  table  7  for  all  presentation  data  values  transferred. 


C.3.11     ASE  Specific  Specifications 


C.3.11.1      Simplification  and  relaxation 


C.3. 11.1.1         Simplification  to  FTAM-1 

This  simplification  loses  information. 

The  document  type  NBS-12  may  be  accessed  as  a  document  type  RAM-1.  The  resultant  document 
contains  the  same  sequence  of  data  values  as  would  result  from  accessing  the  structured  text  file  in 
access  context  UA.  That  is.  only  the  presentation  data  values  in  the  abstract  syntax  "asnamel"  are 
present.  If  the  "cfiaracter-set"  parameter  was  present  before  the  simplification,  its  contents  will  be  added 
to  the  beginning  of  each  string. 

NOTE  -  The  boundary  between  file  access  data  units  remains  a  boundary  between  strings,  but  any  special 
significance  given  to  it  is  lost. 


0.3. 1 1 . 1 .2         Relaxation  to  FTAM-2 

The  document  type  NBS-12  may  be  relaxed  to  the  document  type  FTAM-2.  If  the  "character-set" 
parameter  was  present  before  the  relaxation,  its  contents  will  be  added  to  the  t>eginning  of  each  string. 


0.3. 1 1 . 1 .3        Oharacter  set  relaxation 

This  operation  loses  explicit  information  in  the  document  type  identification. 
A  document  of  type  NBS-12  may  be  relaxed  to  a  different  document  of  type  NBS-12  with 
a  different  "universal-class-number"  parameter  value; 

a  different  "character-set"  parameter  value; 
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a  different  "universal-class-number"  parameter  value  and  no  "character-set"  parameter  value;  or 

no  "character-set"  parameter  value 

if  the  resultant  document  type  permits  all  characters  from  the  original  document  type.  If  this  relaxation 
involves  including  format  effectors  and  none  were  present  before  the  relaxation,  the  characters  'caniage 
return"  and  "line-feed"  shall  be  added  to  the  end  of  each  string. 

NOTE  -  If  the  characters  "carriage  return"  and  'line  feed"  are  not  part  of  the  format  effectors,  the  formatting 
action  may  be  represented  by  "newline,"  or  some  other  implementation  specific  choice  if  there  is  no 
representation  of  'newline'  defined. 


C.3. 1 1 . 1 .4        String  length  relaxation 

This  operation  loses  explicit  infornnatlon  in  the  document  type  identification. 

A  document  of  type  NBS-12  may  be  relaxed  to  another  document  type  NBS-12  with  a  larger  "maximum- 
string-length"  parameter. 


C.3.1 1 .2      Access  context  selection 

A  document  of  type  NBS-12  may  t>e  accessed  in  any  one  of  the  access  contexts  defined  in  the 
sequential  flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived 
from  the  structuring  elements  defined  for  that  access  context  in  ISO  8571  -2. 


C.3.11.3      The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-12  document  type  with  the  same  parameter 
values  in  access  context  FA. 
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Annex  D  (normative) 


Constraint  Sets 

D.I     NBS  random  access  constraint  set 

Table  8  -  Basic  constraints  In  ths  NBS  Random  Access  Constraint  Set 


Constraint  set  descriptor 

*NBS  random  access  constraint  sef 

Constraint  set  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  con8traint-set(4) 
nt)8-random-access(2) } 

Node  names 

All  names  shall  be  of  the  same  type;  the  type  of  the  names 
and  an  ordering  of  the  names  shall  be  defined  when  reference 
is  made  to  the  constraint  set. 

File  access  actions 

Locate,  Read,  Insert,  Erase,  Replace 

Qualified  actions 

None 

Available  access  context 

UA 

Creation  state 

Root  node  without  an  associate  data  unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected 

Read  whole  file 

Read  in  access  context  UA  with  FADU-ldentity  of  ''t}egin* 

Write  whole  file 

Transfer  a  series  of  leaf  FADUs  which  would  t^e  generated  by 
reading  the  whole  file  in  access  context  UA;  perform  the 
transfer  with  a  FADU  Identity  of  'end'  and  a  file  access  action 
of  "insert,"  or  with  a  FADU  Identity  of  'begin"  and  an  action  of 
"replace,"  or  with  an  FADU  identity  of  'node  number"  and  an 
action  of  'replace." 
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 Tabte  9  -  Mentlty  congtrainte  In  the  NBS  Random  Access  Constraint  Set  


Action 

Begin 

End 

NodeSeq 

Node  number 

Locate 

leaf 

Read 

whole 

leaf 

_  — — — 

Insert 

leaf 

Erase 

wtiole 

leaf 

Repiaoe 

whole 

teaf 

NOTE  -  NodeSeq  =  A  sequence  of  Node-Names  with  a  single  member 

D.1.1       Field  of  application 

The  NBS  Random  Access  constraint  set  applies  to  files  which  are  structured  into  a  sequence  of 
irKJMdual  FADUs  and  to  which  access  may  be  made  randomly  by  NodeSeq.  The  structuring  of  the  file 
irito  individual  FADUs  is  determined  by  the  Node-Name. 

D.I. 2      Basic  constraints 

The  basic  constraints  in  the  NBS  Random  Access  constraint  set  are  given  in  table  8. 
D.I. 3      Structural  constraints 

The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the  root  node  shall  be  leaf  nodes 
and  shall  have  an  associated  data  unit;  all  arcs  from  the  root  node  shall  be  of  length  one. 

D.I. 4      Action  constraints 

Insert:  the  insert  action  is  allowed  only  at  the  end  of  the  fHe,  with  FADU-identity  of  "end";  the  new  node 
is  inserted  foilowing  all  existing  nodes  in  the  file.  The  location  following  the  insert  is  'erxl.' 

Erase:  the  erase  action  is  allowed  at  the  root  node  to  empty  the  file,  with  FADU-ldentity  of  'begin.'  The 
result  is  a  solitary  root  node  without  an  associated  data  unit.  Erase  with  the  FADU-ldentlty  of  'node 
number"  means  truncation  of  the  file. 

Replace  whole  file:  the  FADU-ldentity  is  "begin"  and  the  complete  series  of  new  FADU  contents  Is  sent 

Replace  new  leaves:  the  FADU-ldentity  is  "node  number"  and  the  number  of  FADUs  being  replaced  is 
given  by  the  number  of  FADUs  sent. 
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D.I  .5      Identity  constraints 

The  FADU-ldentity  associated  with  the  fiie  action  shall  be  one  of  the  identities:  begin,  end,  Node 
Number  and  NodeSeq.  The  actions  with  which  these  identities  can  be  used  are  gK'en  In  table  9. 
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Annex  E  (normative) 
Abstract  Syntaxes 


E.1     NBS  Node  Name  Abstract  Syntax 

Abstract  Syntax  Name 

{  ISO  identifled-organization  oiw(l4)  ftam8ig(5)  ak)stract-syntax(2)  nbSHXxJe-name(3)  } 

'NBS  random  access  node  name  abstract  syntax" 

This  is  an  at)stract  syntax  for  the  user-coded  Node-Name  in  the  RAM  FADU  abstract  syntax. 
NBS-AS3DERNiTiONS::» 
BEGiN 

NBS-Node-Name::=  SEQUENCE 

{        starting-fadu  [0]  iMPUCIT  iNTEQER. 
fadu-count  [1]  iMPUCiT  iNTEGER  } 
-a  "fedu-counf  of  0  specifies  the 
-range  of  FADUs 

-beginning  at  "starting-tadu"  and 
-ending  at  'end  of  file' 

END 

For  this  at)stract  syntax  the  foiiowing  transfer  syntax  can  be  used. 

{ Joint-iso-ccitt  asnl(l)  basic-encoding(l)  } 
'BiEisic  Encoding  of  a  singie  ASN.1  type' 
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E.2     NBS  Random  Binary  Access  Fils  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  kJantifled-organization  oiw(14)  ftamsig(5)  ab8tract-8yntax(2)  nb8-random-binary(4)  } 
*NBS  random  binary  access  file  abstract  syntax" 

This  Is  an  abstaatit  syntax  for  the  transfer  of  the  file  contents  for  NBS  random  binary  files. 
NBS-AS4  DEHNmONS::  = 
BEGIN 

NBS-Random  Binary     OCTET  STRING 
-contains  one  or  more  presentation  data  values 
-concatenated  together. 
-Each  presentation  data  value  is  defined  as 
-Datatypel  in  table  4. 

END 

For  this  abstract  syntax,  the  following  transfer  syntax  can  be  used: 

{ Joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.l  type' 
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E.3     NBS  Simple  Text  Abstract  Syntax 

Abstract  Syntax  Name 

{iso  identlfied-organlzation  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-simple-text(5)  } 

"NBS  simple  text  at)stract  syntax" 

NBS-AS5  DEFINmONS::  = 

BEGIN 

NBS-Text::=  CHOICE  { 

IA5String,-Unlversal  Class  22 
GraphicString,  -Universal  Class  25 
VisibleString.  -Universai  Qass  26 
GeneralString  -Universal  Class  27  } 

END 

For  this  at)stract  syntax,  the  following  transfer  syntax  can  bo  used: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  encoding  of  a  single  ASN.1  type" 
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Annex  F  (normative)  

Delta  Protocol  Implementation  Conformance  Statement  (PICS)  Pro 
forma 

(Refer  to  the  Working  Implementation  Agreements.) 
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Annex  G  (normative) 
Amendments  and  Corrigenda 

Implementations  conforming  to  these  agreements  shall  implement  the  defect  report  solutions  contained 
in  the  following: 

FTAM: 

a)  ISO  8571 -1/Cor.1:1 990; 

b)  ISO  8571 -2/Cor.1:1990; 

c)  ISO  8571 -3/Cor.1:1 990; 

d)  ISO  8571 -4/Cor.1:1 990; 

e)  ISO  8571 -3/Cor.2; 

,  .    .  .  f)  ISO  8571 -4/Cor.2. 

Editor's  Note  -  The  corrigenda  ISO  8571-3/Cor.2,  and  ISO  8571-4/Cor.2  is  to  be  published.  Until  it  is 
available,  the  solutions  can  be  found  in  the  documents  ISO/IEC  JTC/SC21  N5234  and  ISO/IEC 
JTC1/SC21  N  5235. 
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Foreword 
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the  previously  existing  chapter  on  Directory  Services  Protocol. 
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pages.  Deleted  and  replace  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 


ii 


Part  11  -  Directory  Services  Protocols 

Table  of  Contents 


December  1992  (Stable) 


Part  11  -  Directory  Services  Protocols    1 

0  Introduction   1 

1  Scope    1 

2  References    3 

2.1  Normative  References   3 

2.1.1  Base  Edition  of  tfie  Directory  Standard    3 

2.1.2  Extended  Edition  of  the  Directory  Standard   4 

2.2  Informative  References    4 

3  Status    5 

4  Use  of  the  Directory    5 

5  Directory  ASEs  and  Application  Contexts   5 

6  Schema   6 

6.1  Support  of  Structures  and  Naming  Rules   6 

6.2  Support  of  Object  Classes  and  Subclasses    7 

6.3  Support  of  Attribute  Types   7 

6.4  Support  of  Attribute  Syntaxes    7 

6.5  Naming  Contexts    7 

6.6  Common  Profiles    8 

6.6.1  OIW  Directory  Common  Application  Directory  Profile   8 

6.6.1.1  Standard  Application  Specific  Attributes  and  Attribute  Sets   8 

6.6.1.2  Standard  Application  Specific  Object  Classes   8 

6.6.2  OIW  Directory  Strong  Authentication  Directory  Profile   9 

6.6.2.1  Other  Profiles  Supported   9 

6.6.2.2  Standard  Application  Specific  Object  Classes   9 

6.7  Restrictions  on  Object  Class  Definitions   9 

7  Pragnnatic  Constraints   10 

7.1  General  Constraints   10 

7.1.1  Character  Sets   10 

7.1.2  DSP  APDU  Size   10 

7.1.3  Service  Control  (SC)  Considerations    10 

7.1.4  Priority  Service  Control   10 

7.2  Constraints  on  Operations   11 

7.2.1  Filters   11 

7.2.2  Errors    11 

7.2.3  Error  Reporting  -  Detection  of  Search  Loop   11 

7.3  Constraints  Relevant  to  Specific  Attribute  Types   12 

iii 


Part  11  •  Directory  Services  Protocols  December  1992  (Stable) 

S      Conformanco   12 

8.t       DUA  Conformance    13 

8.2  DSA  Conformance   13 

8.3  DSA  Conformance  Classes     14 

8.3.1  Conformance  Class  0  -  Centralized  DSA    14 

8.3.2  Conformance  Class  1  -  Distributed  DSA   14 

8.4  Authentication  Conformance   14 

8.5  Directory  Service  Conformance   15 

8.5.1  Service  Confomiance   15 

8.5.1.1  r:  required    15 

8.5.1.2  n:  not  required   16 

8.5.2  Protocol  Conformance    16 

8.5.2.1  M:  mandatory   16 

8.5.2.2  G:  generate    16 

8.5.2.3  S:  support   16 

8.5.2.4  0:  optional   17 

8.6  The  Directory  Access  Profile    17 

8.7  The  Directory  System  Profile   17 

8.8  Digital  Signature  Protocol  Conformance  Profile   18 

8.9  Strong  Authentication  Protocol  Conformance  Profile   18 

8.10  Subtree  Specification  Classes    18 

8.11  Replication  Conformance   18 

8.11.1  Shadowing  Roles     18 

8.11.2  Minimum  Shadowing  Requirements   19 

8.11.3  Support  for  Unit  of  Replication    19 

8.12  Recommended  Practices  for  Shadowing     20 

8.12.1  APDU  Size   20 

8.12.2  Duplicate  Shadow  Agreements    20 

8.12.3  Consistency  Between  Supplier  and  Consumer  Information    20 

8.12.4  Management  of  Shadowing  Agreements  Without  DOP    20 

9  Distributed  Operations   21 

9.1  Static  Requirements    21 

9.1.1  Reference  Types   21 

9.1.2  Superior  References  and  Root  Contexts   21 

9.1.2.1  First-Level  DSAs   21 

9.1.2.2  Return-Cross-References   21 

*               9.1.3           Support  of  Application  Contexts    22 

9.1.4  DSA-level  Security   22 

9.1.5  Aliases   22 

9.1.6  Authentication  for  DSA  Bind    22 

9.1.7  Authentication  of  User  Whose  Entiv  Is  Held  by  Another  DSA    22 

9.2  Dynamic  Requirements   22 

9.2.1  Detection  of  Search  Loop   22 

9.2.2  Generation  of  Trace  Information    23 

9.2.3  Integrity  of  Operation  Arguments   23 

i               9.2.4           Referrals  and  Chaining   23 

10  Underiying  Services   23 

iv 


Part  11  -  Directory  Services  Protocois  December  1992  (Stable) 

10.1  ROSE   23 

10.2  Session    24 

10.3  ACSE   24 

11  Access  Control    24 

12  Test  Considerations   24 

12.1  Major  Elements  of  Architecture    24 

12.2  Search  Operation   25 

13  Enrors    25 

13.1  Permanent  vs.  Temporary  Service  Errors   25 

13.2  Guidelines  for  Error  Handling   26 

13.2.1  Introduction   26 

13.2.2  Symptoms   26 

13.2.3  Situations   26 

13.2.4  Error  Actions    26 

13.2.5  Reporting   27 

14  Specific  Authentication  Schemes    27 

14.1  Specific  Strong  Authentication  Schemes    27 

14.1.1  EIGamal   28 

14.1.2  One-Way  Hash  Functions   28 

14.1.2.1  SQUARE-MOD-N  Algorithm   28 

14.1.2.2  MD2  Algorithm   28 

14.1.2.3  Use  of  One-Way  Hash  Functions  in  Forming  Signatures   28 

14.1.3  ASN.1  for  Strong  Authentication  Algorithms   28 

14.2  Protected  Simple  Authentication    31 

14.3  Simple  Authentication    31 

Annex  A  (normative) 

Maintenance  of  Attribute  Syntaxes   83 

A.1       Introduction    83 

A.2      General  Rules   83 

A.3      Checking  Algorithms   83 

A.3.1           distinguishedNameSyntax   83 

A.3.2          integerSyntax   83 

A.3.3           telephoneNumberSyntax   84 

A.3.4          countryName   84 

A.3.5           preferredDeliveryMethod   84 

A.3.6          presentationAddress   84 

A.4      Matching  Algorithms   84 

A.4.1           UTCTimeSyntax    84 

A.4.2           distinguishedNameSyntax   85 

A.4.3           easel  gnoreListSyntax   85 


Annex  B  (informative) 


V 


Part  11 -Directoiy  Services  Protocols  December  1992  (Stable) 

Glotaary   86 

Annex  C  (Informative) 

Requirements  for  Distributed  Operations   88 

C.I      General  Requirements   88 

C.  2      Protocol  Support   88 

I               C.2.1           Usage  of  ChainingArguments   88 

C.  2.2          Usage  of  ChainingResults   89 

Annex  D  (informative) 

Guidelines  for  Applications  Using  the  Directory   90 

D.  I      Tutorial   90 

D.  1.1           Overview   90 

D.I  .2          Use  of  the  Directory  Schema   90 

D.  1.2.1        Use  of  Existing  Object  Qasses   90 

D.I. 2.2        Kinds  of  Object  Qasses   90 

D.I. 2.3        Use  of  Unregistered  Object  Classes   91 

D.I. 2.4        Side  Effects  of  Creating  Unregistered  Object  Classes   92 

D.2      Creation  of  New  Object  Classes   93 

D.2.1          Creation  of  New  Subclasses   93 

D.2.2          Creation  of  New  Attributes   93 

D.3      DIT  Structure  Rules   93 

D.4      UseofAETITLE   93 

Annex  E  (informative) 

Template  for  an  Application  Specific  Profile  for  Use  of  the  Directory   95 

Annex  F  (informative) 

BibHography   97 


Vi 


Part  11  -  Directory  Services  Protocols  December  1992  (Stable) 


List  of  Figures 

Figure  1  -  Centralized  directory  model    2 

Figure  2  -  Distributed  directory  model   2 

Figure  3  -  Logical  DSA  application  environment    11 

Figure  4  -  Three  ways  of  creating  two  object  classes   92 


vli 


Part  11 


Directory  Services  Protocols  December  1992  (Stabie) 

List  of  Tables 


Table  1  -  Pragmatic  constraints  for  selected  attributes      32 

Table  2  -  Directory  access  service  support   35 

Table  3  -  DAP  protocol  support   37 

Table  4  -  Directory  system  service  support   48 

Table  5  -  DSP  protocol  support   49 

Table  6  -  DAP  Support  for  Digital  Signature  Protocol  Conformance  Profile   57 

Table  7  -  DSP  support  for  digital  signature  protocol  conformance  profile   58 

Table  8  -  DAP  support  for  strong  authentication  protocol  conformance  profile   59 

Table  9  -  DSP  support  for  strong  authentication  protocol  conformance  profile   60 

Table  10  -  Error  symptoms   61 

Table  1 1  -  Error  situations   66 

Table  12  -  Notation  used  to  describe  error  actions   67 

Table  13  -  Error  actions    69 

Table  14  -  Simple  credential  fields  and  protected  simple  authentication   82 


Viii 


Part  1 1  -  Directory  Services  Protocols 


0  Introduction 

Edttor'S  Note  -  the  text  in  this  Implementation  Agreement  will  be  significantly  reorganized  in  1993  due  to  the 
alignment  and  submission  by  Regional  Workshops  of  Intemational  Standardized  Profiles  ISO/IEC  pdISP  10615 
and  10616.  The  text  in  tese  pdiSPs,  in  some  cases  containing  technical  changes,  will  replace  substantial 
segments  of  the  text  in  this  Agreement.  In  addition,  text  addressing  the  forthcoming  1993  edition  of  the 
Directory  Documents,  currently  interspersed  among  sections  of  this  Agreement,  will  be  moved  to  a  new 
Agreement  appearing  in  Part  28  of  this  document  and  expanded.  Please  refer  to  the  aligned  part  of  the 
Working  Agreements  Document  for  the  most  recent  results  of  these  realignments. 

This  is  an  implementation  Agreement  developed  by  the  Implementor's  Workshop  sponsored  by  the  National 
Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufoctured  by  different  vendors.  This  agreement  is  t)ased  on  and  employs  protocols  developed  in  accord 
with  the  OSI  Reference  Model.  While  this  agreement  introduces  no  new  protocols,  it  eliminates  ambiguities 
in  interpretations. 

This  is  an  implementation  Agreement  for  the  OSI  Directory  based  on  the  ISO  and  CCITT  documents  cited 
in  clause  2  of  this  part(hereafter  referenced  as  Directory  Documents).  Where  technical  differences  between 
the  ISO  and  CCITT  texts  of  these  documents  exist  (e.g..  Transport  Requirements)  the  ISO  texts  are  given 
precedence. 

1  The  Directory  User  Agents  (DUAs)  and  Directory  System  Agents  (DSAs)  provide  access  to  The  Directory 
I  on  behalf  of  humans  and  applications  such  as  Message  IHandling  and  File  Transfer,  Access,  and 
Management.  See  clause  1  for  more  information  on  the  model  used  in  the  Directory. 

This  document  covers  the  Directory  Access  Protocol  (DAP),  the  Directory  System  Protocol  (DSP),  and  the 
Directory  information  Shadowing  Protocol  (DISP)  defined  in  the  Directory  Documents.  A  good  working 
j    knowledge  of  the  Directory  Documents  is  assumed  by  this  chapter.  Ail  terminology  and  abbreviations  used 
but  not  defined  in  this  text  may  be  found  in  those  documents. 


1  Scope 

Centralized  and  distributed  directories  can  both  be  accommodated  in  this  Agreement  by  the  appropriate 
choice  of  protocols  and  pragmatic  constraints  from  those  specified.  Figure  1  illustrates  a  centralized 
directory  and  figure  2  illustrates  a  distributed  directory. 

This  agreement  does  not  cover  interaction  between  co-located  entities,  such  as  a  co-resident  DUA  and  DSA. 
It  also  does  not  specify  the  interface  between  a  user  (person  or  application)  and  a  DUA. Bilateral  agreements 
between  a  DUA  and  DSA  or  DSA  and  DSA  may  be  implemented  in  addition  to  the  requirements  stated  in 
I  this  document.  Conformance  to  this  agreement  requires  the  ability  to  interact  without  the  use  of  bilateral 
agreements  other  than  those  required  in  the  Directory  Documents. 

ji   The  logical  structure  of  the  Directory  Information  Base  (DIB)  is  descrit>ed  in  the  Directory  Documents.  The 
!    manner  in  which  a  local  portion  of  the  DIB  is  organized  and  accessed  by  Its  DSA  is  not  in  the  scope  of  this 
agreement. 
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USER  <  ^>        DUA  < 


USER  <  >        DUA  < 


The  Directory 


DSA 


Figure  1  -  Centralized  directory  model 


Figure  2  -  Distributed  directory  model 
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2.1      Normative  References 

2.1.1       Base  Edition  of  the  Directory  Standard 

ISO/IEC  9594-1 :1990(E),lnfoiTnation  Technology  -  Open  Systems  Interconnection  •  The  Directory  -  Part  1 : 
Overview  of  Concepts,  Models,  and  Services. 

j    ISO/IEC  9594-2:1990(E),lnfomfiation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  2: 


ISO/IEC  9594-3:1 990(E).lnfomiation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  3: 
Al3stract  Service  Definition. 


ISO/IEC  9594-4:1990(E),lnformation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  4: 


\  ISO/IEC  9594-5: 1990(E),lnformation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  5: 
I    Protocol  Specifications. 

\  ISO/IEC  9594-6:1 990(E).lnformation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  6: 
.    Selected  Attribute  Types. 

\     ISO/IEC  9594-7:1990(E),lnformation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  7: 
Selected  Object  Classes. 

ISO/IEC  9594-8:1990(E),lnformation  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  8: 
Authentication  Framework. 

CCITT  Recommendation  X.500:1988,The  Directory  -  Overview  of  concepts.  Models  and  Services. 
CCITT  Recommendation  X.501:1988,The  Directory  -  Models. 
CCITT  Recommendation  X.509:1988,The  Directory  -  Authentication  Framework. 
CCITT  Recommendation  X.511:1988,The  Directory  -  Abstract  Servk:e  Definitk)n. 
CCITT  Recommendation  X.518:1988.The  Directory  -  Procedures  for  Distributed  Operatkxis. 
CCITT  Recommendation  X.519:1988.The  Directory  -  Protocol  Specifteattons. 
CCITT  Recommendation  X.520:1988,The  Directory  -  Selected  Attribute  Types. 
CCITT  Recommendation  X.521:1988,The  Directory  -  Selected  Ot)ject  Classes. 


Models. 


Procedures  for  Distributed  Operation. 
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The  following  references  represent  a  forthcoming  edition  of  the  OSI  Directory  standard.  Alignment  to  that 
edition  within  these  agreements  is  only  where  expiicitly  indicated  within  particular  sul^clauses. 

ISO/IEC  9594-1  /  DAM-1.2  for  Replication,  Schema,  and  Access  Control. 

ISO/IEC  9594-2  /  DAM-1 .3  for  Access  Control. 

ISO/IEC  9594-2  /  DAM-2.2  for  Schema. 

ISO/IEC  9594-2  /  DAM-3.2  for  Replication. 

ISO/IEC  9594-3  /  DAM-1 .3  for  Access  Control. 

ISO/IEC  9594-3  /  DAM-2.2  for  Replication,  Schema,  and  Enhanced  Search. 
ISO/IEC  9594-4  /  DAM-1 .3  for  Access  Control. 

ISO/IEC  9594-4  /  DAM-2.2  for  Replication,  Schema,  and  Enhanced  Search. 

ISO/IEC  9594-5  /  DAM-1 .2  for  Replication. 

ISO/IEC  9594-6  /  DAM-1.2  for  Schema. 

ISO/IEC  9594-7  /  DAM-1 .2  for  Schema. 

ISO/IEC  9594-8  /  DAM-1.2  for  Access  Control. 

ISO/IEC  9594-9  /  DIS  for  Replication. 

2.2      Informative  References 


Directory  implementors'  Guide,  Version  6,  July  1001 
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4    Use  of  the  Directory 

Given  tlie  rapid  multiplication  and  expansion  of  OSI  applications,  telecommunication  systems  and  services, 
there  is  growing  need  for  users  of  OSI  applications,  as  well  as  the  applications  themselves,  to  communicate 
with  each  other.  In  order  to  facilitate  their  communications,  a  Directory  protocol,  as  referenced  in  these 
agreements,  has  been  tailored  to  meet  their  respective  needs. 

In  one  instance.  The  Directory  will  be  used  as  a  service  to  provide  humans,  in  an  on-line  fashion,  rapid  and 
easy  retrieval  of  information  useful  for  determining  what  telecommunications  services  are  available,  and /or 
how  to  access,  and  address  their  correspondents.  Further,  service  providers  offering  such  a  Public  Directory 
may  also  use  this  service  internally  with  other  various  telecommunications  services  (e.g.,  MIHS)  for  the 
proper  addressing  of  calls  or  messages.  Likewise,  this  does  not  preclude  the  usage  of  these  agreements 
to  similarly  generate  a  privately  operated  Directory  that  supports  both  human  and  application  information 
exchanges. 

In  another  instance.  The  Directory,  will  be  used  as  a  service  by  computer  applications  without  direct  human 
involvement.  One  important  service  is  to  provide  Presentation  Address  resolution  for  named  objects,  on 
behalf  of  OSI  applications.  The  Directory  may  be  used  by  applications  to  search  for  objects  (i.e..  Application 
Entities),  without  direct  human  involvement,  by  the  use  of  the  "search"  or  "list"  operations. 

To  support  the  many  possible  usages.  The  Directory  is  a  general  purpose  system.  It  is  capable  of  storing 
data  of  many  different  forms  as  attributes  within  entries,  and  is  also  capable  of  supporting  simple  or  complex 
hierarchical  structures,  with  variations  in  structure  possibly  occurring  between  one  part  of  The  Directory  and 
another. 

Compliant  DSA  Implementations  should  safeguard  this  generality,  where  possible,  by  placing  the  minimum 
of  restrictions  in  "hard-wired"  form. 


5    Directory  ASEs  and  Application  Contexts 

This  dause  highlights  the  ASEs  (Application  Service  Elements)  and  Application  Contexts  defined  in  the 
Directory  Documents  and  of  concem  in  these  Agreements.  The  functionality  of  the  Directory  AEs  (DUAs  and 
DSAs)  is  defined  by  a  set  of  ASEs,  each  Directory  ASE  specifying  a  set  of  Directory  operations. 

The  interaction  between  these  AEs  is  described  in  terms  of  their  use  of  ASEs.  This  specific  combination  of 
a  set  of  ASEs  and  the  rules  for  their  usage  defines  an  application  context. 

The  following  ASEs  are  described  in  the  Directory  Documents: 

a)  Read  ASE  f)  Chained  Modify  ASE 

b)  Chained  ASE  g)  Operational  Binding  Management  ASE 
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c)  Search  ASE  h)  Shadow  Supplier  ASE 

d)  Chained  Search  ASE  i)  Shadow  Consumer  ASE 

e)  Modify  ASE 

I 

ROSE  and  ACSE  also  form  part  of  the  Directory  Application  Contexts. 

i 

The  following  Application  Contexts  (ACs)  are  described  in  the  Directory  Document: 

a)  Directory  Access  Application  AC  e)  Shadow  Consumer  Initiated  AC  | 

b)  Directory  System  AC  f)  Reliable  Shadow  Supplier  Initated  AC  | 

c)  Directory  Operational  Binding  Management  AC     g)  Reliat>le  Shadow  Consumer  Initated  AC 

d)  Shadow  Supplier  Initiated  AC  v 


6  Schema 

There  are  seven  (7)  major  topics  that  relate  to  schema. 


6.1      Support  of  Structures  and  Naming  Rules 

DSAs  shall  be  capable  of  supporting  (subject  to  refinements  laid  down  in  these  Agreements)  the  structure  I 

and  naming  rules  defined  in  the  Directory  Documents,  Part  7,  Annex  B.  |l 

i 

Part  7,  Annex  B  of  the  Directory  Documents  provides  a  framework  for  the  basic  use  of  the  Directory  in  terms  i 

of  the  objects  defined  in  Part  7.  It  does  not,  however,  form  part  of  the  standard  and.in  any  case,  permits  i 

structures  and  practices  which  may  be  undesirat>le.The  guidelines  below  provide  tighter  control  within  the  |i 

Annex  B  framework.  j 

It  is  recommended  that  only  an  entry  subordinate  to  Root  or  Country  may  use  a  StateOrProvinceName  AVA  i 

i 


If 
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as  an  RON. 


6.2      Support  of  Object  Classes  and  Subclasses 

The  DBAs  shall  be  able  to  support  all  superclasses  of  the  supported  object  classes  (e.g.,  Top,  Person). 

Use  of  an  object  class  in  this  profile  or  the  standard  (or  a  subclass  derived  from  one  or  more  of  these  object 
classes)is  recommended  wherever  the  semantics  are  appropriate  for  the  application.The  derivation  of  a  new 
object  class  as  an  immediate  subclass  of  Top  should  be  avoided.  For  example,  to  represent  printers  in  the 
Directory,  one  can  derive  a  subclass  of  Device. 

An  entry  of  a  particular  object  class  may  contain  any  optional  attribute  listed  for  it  in  the  Directory 
Documents;  a  conformant  DSA  shall  be  able  to  support  all  these  optional  attributes. 

In  addition,  a  DSA  may  permit  any  locally  registered  attribute,  or  a  subset  of  these,  by  providing  the  local 
extension  facilities  permitted  by  unregistered  object  classes  (viz.  Directory  Documents,  Part  2,  clause  9.4.1 
(a)  and  Note). 


6.3      Support  of  Attribute  Types 

I   DSAs  shall  be  able  to  support  the  storage  and  use  of  attribute  type  information,  as  defined  in  the  Directory 
'l\   Documents,  Part  6,  including  their  use  in  naming  and  access  to  entries;  they  shall  also  support  the  definition 
of  new  attribute  types,  making  use  of  pre-existing  attribute  syntaxes. 

i||  DSAs  shall  support  the  encoding,  decoding,  and  matching  of  all  the  attributes  in  the  Naming  Prefixes  of 
i  every  naming  context  they  hold  (ref  Directory  Documents,  Part  4,  clause  9).  These  attributes  may  include 
|>|  attributes  that  are  not  permitted  to  appear  in  entries  in  those  naming  contexts. 


I    Suggested  methods  for  the  interpretation  of  selected  Attribute  Syntaxes  are  defined  in  annex  A. 

6.5      Naming  Contexts 

The  root  of  a  naming  context  shall  not  be  an  alias  entry. 


6.4      Support  of  Attribute  Syntaxes 
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6.6     Common  ProfiSes 

This  subclause  identifies  profiles  that  are  commonly  useful  for  various  applications  wiiiie  an 
application-specific  profile(s)  is  identified  by  the  application. 

6.6.1       OIW  Directory  Common  Application  Directory  Profile 

6.6.1.1  Standard  Application  Specific  Attributes  and  Attribute  Sets 

The  attributes  and  attribute  sets  in  the  Directory  Document,  Part  6,  associated  with  the  object  classes  listed 
below  are  required. 

6.6.1.2  Standard  Application  Specific  Object  Classes 

DSAs  shall  be  able  to  support  storage  and  use  of  the  object  classes  t>elow,  as  defined  in  the  Directory 
Documents,  Part  7,  and  these  object  classes  are  expected  to  be  useful  for  a  range  of  applications. 

The  following  object  classes  are  mandated  by  the  standard: 

a)  Top: 

b)  DSA; 

c)  Alias. 

The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  the  upper  portion  of  the 
DIT: 

a)  Country; 

b)  Locality; 

c)  Applicatbn  Process; 

d)  Organization; 

e)  OrganizationalUnit. 

The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  DIT  leaf  entries: 

a)  Alias; 

b)  AppiicationProcess; 

c)  ApplicationEntity; 
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d)  DSA; 

e)  Device: 

fi  Group  of  Names; 

g)  OrganizatlonalPerson; 

h)  OrganlzationalRole; 
0  ReskJentialPerson. 


6.6.2       OIW  Directory  Strong  Authentication  Directory  Profile 


This  profile  is  used  In  conjunction  with  the  OIW  Directory  Common  Application  Directory  Profile. 


i  The  following  object  classes  are  expected  to  be  generally  useful  for  applications  to  support  strong 
I  authentication: 

a)  Strong  Authentication  User; 

i  b)  Certification  Authority. 


j  6.7     Restrictions  on  Object  Class  Definitions 

jj  An  object  class  may  not  be  defined  as  a  subclass  of  itself,  as  the  chain  of  superclasses  of  such  an  object 

1  class  would  be  a  dosed  loop,  isolated  from  all  other  object  classes,  specifically  Top.  Such  isolation  is  clearly 

il  Illegal. 


6.6.2.1 


Other  Profiles  Supported 


6.6.2.2 


Standard  Application  Specific  Object  Classes 
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7    Pragmatic  Constraints 

This  clause  describes  pragmatic  constraints  to  which  a  confonnant  implementation  shaii  adhere  in  addition 
to  those  specified  in  the  Directory  Documents.  The  pragmatic  constraints  can  be  divided  into  two  major 
areas.  The  first  includes  those  aspects  of  pragmatic  constraints  which  apply  to  scope  of  service  (see  7.1  and 
7.2).  The  secoTKl  includes  those  aspects  of  pragmatic  constraints  which  are  specific  to  particular  attribute 
types  (see  7.3). 


7.1      General  Constraints 

7.1.1  Character  Sets 

it  is  a  requirement  to  support  ail  character  sets  and  other  name  fomns  defined  in  the  Directory  Documents,  | 
Part  6.  Those  character  sets  include: 

a)  T.61: 

b)  PrintableString: 

c)  NumericString. 

7.1.2  DSP  APDU  Size  ] 


In  the  process  of  chaining  requests  it  is  possible  that  a  chaining  DSA  may  receive,  invoice  or  retum  APDUs  i  j 
that  exceed  its  capacity,  it  is  a  minimum  requirement  that  invoice  APDUs  and  retum  result  APDUs  shall  be  .\ 
accepted  unless  they  exceed  2**18  - 1  (i.e.,  262,143)  octets  in  size;in  this  case  they  may  be  discarded  and  | 
an  "unwilingToPerform"  error  reporting  service  shall  be  used. 


7.1.3       Service  Control  (SC)  Considerations 


This  agreement  recognizes  that  DUAs  may  automatically  supply  defaults  for  any  SC  parameter.  The  choice 
of  defoult  values  selected  (if  any)  is  seen  to  be  a  matter  of  local  policy  and  consumer  needs. 


7.1.4       Priority  Service  Control 

Priority  is  specified  as  a  service  control  argument  in  the  Directory  Documents.  The  following  statements  < 
represent  a  clarification  of  the  semantics  that  may  be  used  by  a  DSA  in  interpreting  and  operating  on  this  ' 
parameter. 

The  logical  model  in  figure  3  may  be  considered  as  an  example  by  DSAs  that  implement  this  Service  i 
Control.  In  figure  3,  note  that:  ' 

a)  the  DSA  maintains  three  logical  queues  corresponding  to  the  three  priority  levels; 
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b)  the  DSA  Scheduler  is  separate  and  distinct  from  any  scheduling  function  provided  by  the 
underlying  operating  system  or  control  program  services; 

c)  the  DSA  Scheduler  presents  Jobs  to  the  Underlying  Operating  Services  for  execution  and  always 
presents  jobs  of  a  higher  priority  before  those  of  a  lower  priority; 

d)  the  DSA  Scheduler  will  not  preempt  a  request  once  it  has  been  passed  to  the  underlying 
operating  system  service. 


High 


Medium 


Low 


V 


DSA 

Scheduler 


V 


Underlying 
iProtocol  Services 


Underlying  OS 
Services 


Figure  3  -  Logical  DSA  application  environment 

'  7.2     Constraints  on  Operations 

f\  There  are  no  overall  constraints  upon  service  arguments  or  results  except  those  implied  in  7.1.2  of  this 
1^  document. 


7^.1 


Filters 


I  It  is  required  that  DSAs,  at  a  minimum,  support  8  nested  "Filter"  parameters,  and  a  total  limit  of  32  Filter 
!l  ltems.lf  these  limits  are  exceeded,  the  recipient  of  that  Search  Argument  may  return  the  Service  Problem 


I  "unwillingToPerform. 


t  7.2.2  Errors 

'  There  are  no  constraints  upon  any  Error  service  except  the  APDU  size  limit  as  defined  in  7.1.2. 

HI  7.2.3       Error  Reporting  -  Detection  of  Search  Loop 

A  search  operation  may  encounter  a  looping  situation  when  the  search  encompasses  "whole-subtree,"  and 
i  an  alias  is  encountered  which  is  a  superior  to  some  other  subtree  that  has  been  encountered  during  the 
iii  search. 


i 
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DSAs  should  be  able  to  detect  this,  situation.  One  possible  method  is  by: 

a)  Maintaining  a  list  of  the  t>ase  objects  of  searches  initiated  as  a  consequence  of  Step  5  of  Part 
4.  clause  18.7.2.2.1  of  the  Directory  Documents  (this  may  require  an  analysis  of  theTracelnformation 
field): 

b)  Determining  whether  a  new  base  object  is  superior  to  any  base  object  on  this  list. 

A  new  base  object  which  would  cause  a  loop  in  this  way  should  be  discarded  (i.e.,  should  not  cause  a  new 
search),  but  no  error  should  be  reported  by  an  error-reporting  service.  The  circumstances  should  be  logged 
so  that  it  may  be  reported  to  an  appropriate  Administrative  Authority  for  rectification. 

7.3      Constraints  Relevant  to  Specific  Attribute  Types 

Table  1  gives  pragmatic  constraints  associated  with  selected  attribute  types  specified  in  the  Directory 
Documents;  many  of  these  constraints  also  appear  and  are  the  same  in  the  CCITT  version  of  the  Directory 
Documents.  Each  constraint  in  table  1  is  given  in  terms  of  a  length  constraint.  The  length  constraint  for  a 
given  attribute  value  is  the  numt>er  of  units  which  a  sending  entity  shall  not  exceed  and  which  a  receiving 
entity  shall  accept  and  process.  A  sending  entity  need  not  be  capable  of  sending  attribute  values  as  large 
as  the  length  constraints. 

Note  that  in  table  1  the  length  constraint  for  strings  is  expressed  as  the  number  of  allowable  characters, 
in  addition  to  the  constraints  given  in  table  1 ,  the  following  constraints  apply  to  alphabets  and  integer  values: 

a)  Alphabets:  T.61  Strings  used  as  attribute  values  shall  only  encode  graphic  characters  and 
spaces.  They  shall  not  contain  formatting  characters  (such  as  subscript)  or  other  control  characters; 

b)  Integer  Values:  DSAs  shall  be  required  to  "pass  through"  encoded  integer  attribute  values  of 
arbitrary  length  (e.g.,  when  chaining  a  Directory  operation).  No  Directory  component  (i.e.,  DUA  or 
DSA)  shall  be  deemed  non-conformant  if  it  encodes  integer  attribute  values  of  arbitrary  length. 

Components  of  the  Directory  are  required  to  support  (for  storage  and  processing),  as  a  minimum,  integer 
attribute  values  encoded  in  4  octets. 


8  Conformance 

The  following  subclauses  will  describe  various  aspects  of  Directory  conformance.  It  should  be  noted  that 
conformance  to  the  various  ASEs  and  conformance  to  the  Authentication  Framework  are  viewed  as  separate 
issues  and  are  presented  in  that  context. 
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8.1      DUA  Conformance 

Conformance  requirements  for  DUAs  are  adequately  specified  In  the  Directory  Documents,  Part  5,  clause 

9.1  and  the  Directory  Access  Profile  (see  8.6).  It  should  be  noted  that  the  DUA  confonnance  is  based  on 
DAP  Protocol  and  not  the  User  Interfece.  Not  all  options  available  in  the  standard  need  to  be  made  available 
to  the  user  of  the  DUA. 

It  is  recognized  that  DUAs  will  be  widely  differing  In  nature: 

a)  Some  are  intended  to  support  human  users,  some  application  users; 

b)  Particular  DUAs  may  not  support  particular  operations  because  the  application  that  they  support 
has  no  requirement;  others  will  be  general  purpose,  and  will  support  all  operations; 

c)  Some  DUAs  will  have  a  fixed  view  of  the  Directory  content  and  structure,  reflecting  the  usage 
of  The  Directory  by  a  particular  application;  others  will  have  a  more  flexible  view  which  can  be 
adapted  to  new  usages; 

d)  Some  DUAs  will  provide  automatic  refenai  services  with  automatic  establishment  and  release 
of  associations;  others  will  place  the  burden  on  the  user; 

e)  Some  DUAs  will  provide  a  variety  of  authentication  means;  others  will  support  no  authentication; 

f)  Some  DUAs  will  handle  operations  synchronously;  others  will  have  the  capability  of  maintaining 
several  Identifiable  dialogues  with  The  Directory  at  one  time. 

In  the  next  subclause,  different  types  of  DSAs  are  discussed.  The  DUA  is  independent  of  the  type  of  DBA 
it  Is  communicating  with  and  does  not  need  to  know  what  type  of  DSA  it  is  communicating  with. 

8.2  DSA  Conformance 

Basic  conformance  requirements  for  a  DSA  are  defined  in  the  Directory  Documents,  Part  5,  clause  9.2.  Some 
of  the  terms  used  to  describe  DSA  conformance  are  summarized  below: 

a)  Centralized:  A  centralized  DSA  is  defined  as  one  that  contains  its  entire  relevant  DIT;  it  follows 
that  It  will  not  make  use  of  the  DSP  or  generate  referral  responses.  Since  this  model  only  contains 
a  single  DSA  it  is  not  subject  to  DSA  intenvorking  issues  and  will  always  provide  a  consistent  level 
of  service  and  results.  A  centralized  DSA  shall  be  fully  "protocol"  conformant  to  the  DAP; 

b)  Cooperating:  In  a  distributed  directory,  responsibility  for  various  portions  of  the  DIT  may  be 
"distributed"  among  multiple  DSAs.  On  a  per  operation  basis  we  define  a  DSA  to  be  holding  when 
It  is  responsible  for  the  fragment  of  the  DIB  in  which  a  given  entry  will  appear  if  it  exists;  we  define 
a  DSA  to  be  propagating  when  it  is  unable  to  complete  the  name  resolution  process. 

All  DSAs  shall  be  capable  of  acting  as  a  holder  and  a  propagator. 
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8.3      DSA  Conformance  Classes 

A  DSA  implementation  shali  satisfy  the  conformance  requirements  as  defined  in  the  Directory  Documents, 
Part  5,  subclause  9.2,and  shall  support  the  "Versions"  argument  of  "Bind." 

Per  the  conformance  clause  of  the  Directory  Documents,  a  DSA  shall  conform  to  the  at}stract  syntax  of  the 
attribute  types  for  which  conformance  is  claimed.  These  attribute  types  shall  include  those  required  by  6.3 
of  this  Implementor's  Agreement. 

Additionally,  an  implementation  conformant  to  these  agreements  shall  state  which  of  the  following 
conformance  classes  it  implements: 

8.3.1  Conformance  Class  0  -  Centralized  DSA 

A  DSA  conformant  to  this  class  only  supports  the  DirectoryAccessAC. 

As  the  performance  of  Search  and  List  operations  can  consume  significant  resources,  the  policies  of  some 
centralized  DSAs  may  be  such  that  these  operations  will  not  be  performed.  For  these  cases,  the  reply  to 
requests  for  such  operations  would  be  a  Service  Error  with  the  "unwillingToPerform"  Service  Problem. 

8.3.2  Conformance  Class  1  -  Distributed  DSA 

A  DSA  implementation  conformant  to  this  class  shall  implement  all  the  operations  in  the  ASEs  that  are  part 
of  the  Application  context  for  which  it  claims  conformance.  It  shall  support  the  DirectoryAccessAC  and  it 
may  optionally  support  the  DirectorySystemAC. 

DSAs  conformant  to  these  Agreements  shall  support  the  OIW  Directory  Common  Application  Directory 
Profile.  In  addition,  DSAs  may  optionally  conform  to  the  OIW  Directory  Strong  Authentication  Directory 
Profile.  Future  versions  of  these  Agreements  may  allow  additional  possibilities  for  minimal  profile 
conformance. 


8.4     Authentication  Conformance 

A  Directory  System  may  choose  to  implement  various  levels  of  authentication  (Directory  Documents,  Part 
8).  We  define  the  following  levels  of  authentication  in  the  DS: 

a)  No  authentication  at  all;  (None); 

b)  Simple  Uncorroborated:  identification  without  verification; 

c)  Simple  Uncorroborated  authentication  with  verification:  verified  identification  without  a 
password; 

d)  Simple  Corroborated  authentication:  verified  identification  with  a  password;  intended  to  make 
masquerading  difficult; 

e)  Strong  authentication:  identification  with  verification  using  cryptographic  techniques  intended 
to  make  masquerading,  in  practical  terms,  nearly  impossible. 
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The  'Authentication  Framewori<"  document  describes  the  specific  goal  of  each  authentication  level;  listed 
below  are  several  practical  uses  of  the  various  levels.^ 

Simple  Uncorroborated  authentication  may  be  desired  to  maintain  access  statistics  or  In  a  private 
networtt  where  the  initiator  is  implicitly  tmsted  and  there  is  no  need  to  incur  the  additional  overhead 
of  more  sophisticated  authentication  methods. 

Simple  Corroborated  authentication  may  be  necessary  In  situations  where  stror>g  authentication 
is  not  practical,  (i.e.,  international  connection,  no  l(nowledge  of  algorithms  in  use,  etc.). 

Strong  authentication  wHI  be  required  for  secure  environments. 

A  DBA  that  implements  Simple  Corroborated  authentication  wHI  check  the  user  password  by  means  of  a 
compare  operation  on  the  user's  entry.  If  no  user  password  is  supplied  (Simple  UrKXMTotxxated 
authentication)  the  DSA  will  validate  the  presence  of  the  entry  for  the  user,  by  a  read  operation  or  otherwise. 
The  authentication  will  fail  if  the  password  is  incorrect  or  if  the  user's  entry  does  not  exist. 

A  DSA  that  implements  Simple  Uncorroborated  authentication  without  verification  will  accept  simple 
credentials  without  validating  them. 

Implementations  claiming  conformance  shall,  as  a  minimum,  implement  None  and  Simpia  Uncorrotx>rated 
authentication  without  verification. 


8.5     Directory  Service  Conformance 

The  following  subclauses  will  describe  various  aspects  of  Directory  conformance.  Conformance  to  the 
Authentication  Frameworic  is  viewed  as  a  separate  issue  from  confomriance  to  the  rest  of  the  Directory 
document  and  is  presented  in  that  context. 

Directory  Profiles  are  broken  Into  two  subclauses.  Service  support  specifies  the  level  of  support  for 
operations  and  en'ors.  Protocol  support  specifies  the  protocol  elements  required  for  implementations  which 
daim  confomnance  to  specified  operations. 

8.5.1       Service  Conformance 

To  specify  the  support  for  operations  and  errors,  two  classifications  are  used  as  follows. 
8.5.1.1        r:  required 

The  operation  shall  be  implemented  and  the  respective  error  shall  be  handled  for  confonmance  to  these 
agreements. 

For  DUAs.  required  means: 

a)  or  ARGUMENT  parameters,  create  the  DAP  protocol  elements  to  convey  the  service  request  to 
the  DSA; 


^It  is  the  case  that  some  DSAs  containing  public  information  may  not  require  authentication. 
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b)  for  RESULT  and  ERROR  parameters,  accept  the  DAP  protocol  elements. 
For  DSAs.  required  means: 

a)  for  ARGUMENT  parameters,  accept  the  protocol  elements  when  received  and  create  the  protocol 
elements  when  acting  as  a  requesting  DSA; 

b)  for  RESULT  and  ERROR  parameters,  be  able  to  convey  all  possible  results  when  responding  in 
either  the  DAP  or  DSP  protocols  and  when  receiving  results,  perform  additional  processing  as 
defined  for  cooperating  DSAs. 

8.5.1.2        n:  not  required 

It  Is  left  to  implementations  as  to  whether  the  operation  or  error  is  Implemented  or  not. 
8.5.2       Protocol  Conformance 

To  specify  the  support  for  protocol  elements,  four  classifications  are  used  as  follows. 

8.5.2.1  M:  mandatory 

Generation  of  element  is  a  mandatory  static  conformance  requirement  (i.e.,  a  conformant  implementation 
shall  be  capable  of  generating  the  element). 

Generation  of  element  is  a  mandatory  dynamic  conformance  requirement  (i.e.,  the  element  shall  be  present 
in  all  instances  of  communication  which  use  the  element). 

The  terms  static  conformance  and  dynamic  conformance  are  defined  in  ISO  9646-1,  "OSI  Conformance 
Testing  Methodology  and  Framework,  Part  1 :  General  Concepts." 

8.5.2.2  G:  generate 

Generation  of  element  is  a  mandatory  static  conformance  requirement. 

Generation  of  element  is  a  conditional  dynamic  conformance  requirement;  the  condition  is: 

Where  a  DSA  Is  a  propagating  DSA,  it  shall  be  capable  of  generating  the  protocol  element  as  received  in 
related  APDUs  received  from  other  DSAs.  Where  the  DSA  is  a  holding  DSA,  it  shall  be  capable  of  creating 
all  possible  values  of  a  protocol  element  unless  otherwise  noted  in  the  "comments"  line. 

8.5.2.3  S:  support 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  capable  of  accepting  these 
elements  without  error.  Actions  specified  in  the  Directory  documents  and  in  these  agreements  shall  be  taken. 
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8.5.2.4        O:  optional 

When  generating  protocol  elements: 

a)  Generation  of  element  is  an  optional  static  conformance  requirement.  If  the  impienrtentor  claims 
support  for  the  corresponding  Directory  capability,  then  the  implementation  shall  be  capable  of 
generating  the  element; 

b)  Generation  of  element  is  an  optional  dynamic  conformance  requirement.  If  ttie  implementor 
claims  support  for  the  corresponding  Directory  capability,  then  the  element  shall  be  present  In 
Instances  of  communication  which  use  the  element  (except  where  defaults  allow  otherwise). 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  capat)le  of  accepting  these 
elements  without  error.  However,  actions  specified  In  the  t>ase  standard  and  in  these  agreements  may  be 
taken  but  are  not  required. 

Where  protocol  elements  are  nested,  the  classification  of  the  nested  protocol  elements  is  of  relevance  only 
when  the  immediately  containing  protocol  element  Is  generated.  The  classification  of  the  protocol  elenoents 
at  the  highest  level  is  relative  with  respect  to  support  of  the  operation. 

Also  note  that  In  table  3,  some  rows  contain  two  support  classifications  in  the  DSA  column.  In  such  cases, 
the  support  classification  in  parentheses  applies  to  centralized  DSA's  only.  When  there  Is  only  one  support 
classification  given,  it  applies  equally  to  centralized  and  non-centralized  DSA's. 

8.6  The  Directory  Access  Profile 

This  agreement  requires  implementations  of  the  DUA  to  provide  access  to  the  Directory  Services  as  defined 
in  the  DUA  column  in  table  2.  For  the  services  in  table  2  which  are  supported,  these  agreements  further 
require  DUAs  to  support  the  protocol  elements  as  defined  in  the  DUA  column  In  table  3  (parts  1  -  7). 

These  agreements  require  implementations  of  the  DSA  to  support  the  Directory  Services  as  defined  in  the 
DSA  column  in  table  2.  These  agreements  further  require  DSAs  to  support  the  protocol  elements  as  defined 
in  the  DSA  column  in  table  3.  Table  3  is  listed  in  seven  parts.  Note  that  the  requirements  for  a  centralized 
DSA  and  a  cooperating  DSA  are  different. 

8.7  The  Directory  System  Profile 

These  agreements  require  implementations  of  distributed  DSAs  which  provide  DSP  to  support  the  responder 
role  for  services  as  defined  in  table  4.  Further,  these  agreements  require  DSAs  to  support  the  protocol 
elements  as  specified  in  table  5.  Table  5  is  listed  in  nine  parts. 

DSAs  are  required  to  support  the  requestor  role  for  all  the  services  as  defined  In  table  4  If  conforming  to  the 
chained  mode  of  interaction. 
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8.8  Digital  Signature  Protocol  Conformance  Profile 

Table  6  and  table  7  provide  Information  on  the  digital  signature  protocol  conformance  profile. 

Note  that  elements  In  CommonArguments  and  CommonResults  SecurityParameters  that  are  not  specified 
In  table  6  and  table  7  are  covered  In  the  Directory  Service  Protocol  Support  (table  5)  and  Directory  Access 
Protocol  Support  (table  3). 

8.9  Strong  Authentication  Protocol  Conformance  Profile 

Table  8  and  table  9  provide  information  on  the  strong  authentication  protocol  conformance  profile. 

8.10  Subtree  Specification  Classes 

NOTE  -  This  subclause  contains  agreements  on  the  forthcoming  edition  of  the  031  Directory  standard,  and 
is  based  on  the  DAM/DIS  Directory  documents  referenced  in  2.1  of  these  agreements. 

This  profile  defines  three  classes  of  refinement  that  may  occur  in  subtree  specifications.  These  classes  may 
be  used  In  describing  units  of  replication  for  use  by  DISP  or  in  describing  DACDs  for  use  by  Basic  Access 
Control: 

•  Class  0  (Complete  Subtree):  A  subtree  definition  In  which  only  the  base  component  Is  specified; 

•  Class  1  (Chop  Subtree):  A  subtree  definition  in  which  only  the  base  and  chop  components  are 
specified; 

•  Class  2  (Refined  Subtree):  A  subtree  definition  in  which  the  base,  chop,  and  specification-filter 
components  are  specified. 

8.11  Replication  Conformance 

NOTE  -  This  subclause  contains  agreements  on  the  forthcoming  edition  of  the  081  Directory  standard,  and 
is  based  on  the  DAM/DIS  Directory  Documents  referenced  in  2.1  of  these  agreements. 

A  DSA  implementing  DiSP  shall  conform  to  the  basic  conformance  requirements  for  a  DSA  as  defined  In 
the  Directory  Documents,  part  5,  clause  9.2.  However,  it  is  not  required  for  such  a  DSA  to  be  either 
centralized  or  distributed  as  defined  by  8.3  of  this  implementation  agreement. 

8.11.1      Shadowing  Roles 

All  DSAs  implementing  DISP  shall  be  capable  of  acting  both  as  a  shadow  supplier  and  as  a  shadow 
consumer  as  defined  in  the  Directory  Documents,  part  9,  clause  3,  and  as  such  shall  meet  confomriance 
requirements  stated  in  part  5,  9.3  and  9.4. 
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8.11.2  Minimum  Shadowing  Requirements 

Additionally,  conformance  to  this  profile  requires  a  minimum  as  listed  below: 

a)  support  for  both  the  directoryShadowConsumerAC  application  context  and  the 
directoryShadowSupplierAC  application  context; 

b)  support  for  an  updateMode  whose  mode  choice  includes  a  specification  of 
schedulingParameters; 

c)  support  for  schedulingParameters  specifications  which  specify  a  periodic  strategy. 

8.11.3  Support  for  Unit  of  Replication 

This  profile  defines  three  classes  regarding  the  level  of  refinement  to  be  supported  by  a  DSA  in  the  definition 
of  a  unit  of  replication.  The  provider  of  a  conforming  implementation  shall  state  which  of  the  following  Unit 
of  Replication  Conformance  Classes  the  implementation  supports: 

a)  Class  0  (Basic  UnitOf Replication):  A  DSA  conforming  to  this  class  shall  be  capable  of  shadowing 
a  Unit  of  Replication  with  the  following  characteristics: 

1)  the  area  includes  a  class  0  subtree  as  defined  in  8.10  of  these  agreements; 

2)  the  area  includes  a  specified  knowledgeType  (e.g.,  master,  copy,  or  both). 

b)  Class  1  (Intermediate  UnitOf  Replication):  A  DSA  conforming  to  this  class  shall  fully  support  the 
Basic  UnitOfReplication  and,  in  addition,  shall  be  capable  of  shadowing  a  unit  of  replication  with  the 
following  characteristics: 

1)  the  area  includes  a  class  1  subtree  as  defined  in  8.10  of  these  agreements; 

2)  the  l<nowledge  includes  the  extendedKnowiedge  element  with  value  TRUE. 

c)  Class  2  -  (Maximal  UnitOfReplication):  a  DSA  conforming  to  this  class  shall  fully  support  the 
Intermediate  UnitOfReplication  and,  in  addition,  shall  be  capable  of  shadowing  a  unit  of  replication 
whose  specification  uses  AttributeSelection  (including  selection  on  class).  Furthermore,  a  DSA 
conforming  to  this  class  shall  be  capable  of  supporting  overlapping  replicated  areas  as  described 
in  the  Directory  Documents,  part  9,  9.2.5. 

NOTES 

1  No  replication  conformance  class  requires  (nor  precludes)  support  for  a  class  2  subtree  specification. 

2  Filtering  using  a  specification-filter  in  the  definition  of  a  subtree  allows  filtering  on  class  when  specifying 
which  entries  are  to  be  part  of  the  subtree. 

3  AttributeSelection  is  used  in  shadowing  to  determine  which  attributes  of  the  entries  in  a  subtree  will  be 
shadowed.  ClassAttributeSelection  allows  choosing  specific  attributes  or  all  attributes  in  an  class.  A  list  of 
classes  for  shadowing  can  be  devised  using  a  sequence  of  class  and  classAttributes. 
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8.12    Recommended  Practices  for  Shadowing 


NOTE  -  This  subclause  contains  agreements  on  the  forthcoming  edition  of  the  OSI  Directory  standard,  and 
Is  based  on  the  DAM/DIS  Directory  Docunients  referenced  in  2.1  of  these  agreements. 


In  shadowing,  updates  for  an  entire  Unit  of  Replication  are  carred  in  one  APDU.  Since  the  size  of  such  an  | 

APDU  is  application-specific,  no  pragmatic  constraint  has  been  specified  in  the  Directory  Documents  or  j 

Implementation  Agreements.  I 

Some  examples  of  APDU  size  implementors  can  expect  would  be  useful.  For  instance,  an  entry  size  of  2000  1 

octets  and  a  Unit  of  Replication  consisting  of  2000  entries  would  result  in  a  APDU  of  4  Megabytes.  It  Is  j 
recommended  that  DSA  implementations  be  capable  of  supporting  an  APDU  of  at  least  this  size.  This 

example  does  not  reflect  entries  which  Include  large  attributes,  such  as  photographic  images.  , 


8.12.2     Duplicate  Shadow  Agreements 

Administrators  should  not  allow  duplicate  shadow  agreements  between  DSAs.  Duplicate  shadow 
agreements  are  those  which  Include  the  same  consumer,  supplier,  and  Unit  of  Replication. 


8.12.3  Consistency  Between  Supplier  and  Consumer  information 

After  an  updateShadow  operation,  the  standard  does  not  guarantee  consistency  between  the  resulting 
shadowed  Information  in  the  consumer  DSA  and  the  information  In  the  replicated  area  in  the  supplier  DSA, 
since  changes  may  be  made  during  assembly  of  the  APDU  containing  the  shadowed  Information. 

If  consistency  between  the  supplier  and  consumer  information  Is  required,  the  contents  of  the  replicated  area 
in  the  supplier  DSA  must  not  be  modified  while  the  APDU  Is  being  assembled. 

However,  the  shadowed  Information  must  be  internally  consistent.  For  example,  while  the  shadowed 
information  Is  being  assembled,  changing  a  distinguished  name  within  the  replicated  area  could  lead  to 
internal  Inconsistency. 

8.12.4  Management  of  Shadowing  Agreements  Without  DOP 

For  DSAs  not  supporting  the  directoryOperationalBindingManagementAC  as  defined  In  the  Directory 
Documents,  part  5,  management  of  shadowing  agreements  Is  by  out-of-band  means.  The  results  of 
procedures  followed  by  such  DSAs  must  be  the  same  as  if  the  DSAs  had  managed  the  same  agreements 
using  the  procedure  for  operational  binding  management  outlined  in  8.2  of  the  Directory  Documents,  part 
9. 

For  example,  when  shadowing  DSAs  arrange  to  modify  the  parameters  of  an  existing  shadowing  agreement,  ! 
they  must  revise  the  AgreementID  so  that  Its  version  component  is  incremented. 


8.12.1 


APDU  Size 
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9.1      Static  Requirements 


9.1.1       Reference  Types 

This  Functional  Standard  requires  conforming  implementations  to  be  able  to  hold  and  use  reference  types 
as  summarised  below  (and  clarified  in  9.1.2): 


REFERENCE  TYPES 

HOLDING  AND 
USING  CAPABILITY 

NOTES  ™1 

Superior 

see  note 

Non-first-level  DSAs  shall 
hold  precisely  one  single 
superior  reference.  A 
First-Level  DSA  does  not 
hold  any  superior  reference 

Subordinate 

Mandatory 

Non-specific 
Sulx>rdinate 

Optional 

Cross-reference 

Mandatory 

9.1.2       Superior  References  and  Root  Contexts 

9.1.2.1  First-Level  DSAs 

A  DSA  conformant  to  this  Functional  Standard  acting  as  a  first  level  DSA  shall  be  able  to  hold  and  use  the 
root  context  and,  in  addition,  shall  hold  as  master  (i.e.,  have  administrative  authority  for)  at  least  one  naming 
context  immediately  subordinate  to  the  root  of  the  DIT.  A  DSA  conforming  to  this  Functional  Standard  is 
not,  however,  required  to  have  the  capability  of  being  a  first  level  DSA. 

NOTE  -  The  root  context  never  contains  any  non-specific  subordinate  references  and  first  level  DSAs  should 
not  hold  such  references  in  respect  of  the  root  context  to  avod  circular  references. 

9.1.2.2  Return-Cross-References 

The  support  of  the  "return-cross-references"  facility,  either  as  requester  or  as  supplier,  as  defined  in  the 
Directory  Documents,  clause  10.4.,  is  optional. 
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9.1.3  Support  of  Application  Contexts 

AN  DSAs  compliant  with  this  Functional  Standard  shall  support  the  DirectoryAccessAC  or  DirectorySystemAC 
or  both. 

If  a  DSA  supports  DirectorySystemAC,  then  it  must  be  able  to  accept  a  chained  request  and  must  t>e  able 
to  generate  a  referral.  The  generation  of  chained  requests  is  optional.  See  Table  4. 

Editor's  Note  •  Table  4,  refererKed  in  the  above  paragraph,  is  located  in  the  current  stable  agreements. 

9.1.4  DSA-levei  Security 

As  a  consequence  of  security  policy,  a  DSA  may: 

a)  refuse  associations  from  any  or  particular  DSAs; 

b)  refuse  invokes  on  existing  associations  in  which  case  a  SecurityError  or  ServiceError  Is  returned. 

9.1.5  Aliases 

DSAs  shall  t>e  able  to  carry  out  name  resolution  and  search  continuation  for  an  alias  whose  dereference 
points  to  an  entry  held  outside  the  DSA  (as  well  as  those  held  inside  the  DSA). 

9.1.6  Authentication  for  DSA  Bind 

in  the  case  of  simple  auttientication,  if  any  of  the  DSAs  listed  in  the  trace  information  is  untrusted.  the 
originating  user  identified  by  the  originator  field  In  the  chaining  argument  should  be  treated  as 
unauthenticated. 

Editor't  Note  -  Use  of  tracelnfbrmation  in  making  security  decisions  will  be  a  subject  of  continued  discussion 
and  oontrlbutk)n8. 

9.1.7  Authentication  of  User  Whose  Entry  Is  Held  by  Another  DSA 

if  a  DSA  is  to  be  able  to  carry  out  simple  authentication  of  a  user  whose  entry  is  potentially  held  by  some 
other  DSA,  the  DSA  must  be  able  to  invoke  DSA  "compare*  and  "read"  operations  to  complete  authentication 
by  referer)ce  to  other  DSAs.  All  such  DSAs  shall  support  the  DirectorySystemAC. 

9.2     Dynamic  Requirements 

9.2.1       Detection  of  Search  Loop 

Refer  to  7.2.3  of  these  Agreements. 
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9.2.2       Generation  of  Trace  Information 

A  Tracelnformation  value  carries  forward  a  record  of  the  DSAs  which  have  been  involved  in  the  perfonnance 
of  an  operation.  It  Is  used  to  detect  the  existence  of,  or  avoid,  loops  which  might  arise  from  inconsistent 
knowledge  or  from  the  presence  of  alias  loops  In  the  DIT.  Each  DSA  which  is  propagating  an  operation  to 
another,  adds  a  new  item  to  the  trace  Infornration.  If  the  propagation  of  a  Search  operation  involves  the 
creation  of  a  new  Search  (Directory  Documents,  clause  18.7.2.2.2),  the  trace  information  shall  not  be  re-set, 
but  the  full  trace  infonnation  for  the  overall  Search  operation  to  the  point  where  the  new  Search  was 
generated  shall  be  Included  in  the  new  Search. 

There  is  no  arbitrary  limit  on  the  size  of  Tracelnfomnation  other  than  that  imposed  by  the  maximum  APDU 
size  limit. 


9.2.3  Integrity  of  Operation  Arguments 

Any  ak)stract  service  operation  arguments  that  are  signed  must  be  passed  unchanged  to  the  presentation 
layer.  This  does  not  constrain  the  hoice  of  transfer  syntax  used  by  the  presentation  layer. 

9.2.4  Referrals  and  Chaining 

It  is  recommended  that  a  DSA  which  has  chained  a  request  act  upon  any  referrals  which  it  receives,  rather 
than  returning  them  to  the  requestor  if  the  "prefer-chaining"  service  control  is  present,  unless  prevented  from 
doing  so  byadministrative  limitations  or  service  policies. 

However,  if  a  DSA  which  is  carrying  out  a  List  or  a  Search  operation  receives  a  set  of  unexplored 
Continuation  References,  it  shall  never  pursue  these  if  the  result  was  signed  (but  was  not  collated  by  the 
DSA  with  other  results),  since  this  will  result  in  duplication.  If  the  result  was  unsigned,  it  may  act  on  them 
(removing  them  from  the  consolidated  result),  or  it  may  pass  them  back  to  the  Invoker  of  the  operation. 
The  DSA  can  act  on  the  references  and  remove  them  if  correlated. 

If  a  DSA  is  unable  to  establish  an  association  with  a  remote  DSA  for  the  purpose  of  chaining  an  operation, 
then  it  should  return  a  DSA  referral  or  continuation  reference  as  appropriate. 

10  Underlying  Services 

This  section  specifies  requirements  over  and  above  those  given  in  the  Directory  Documents. 

10.1  ROSE 

It  should  be  noted  that  support  of  "abandon"  implies  support  of  operation  class  2. 
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10.3  ACSE 

The  A-ABORT  sen/ice  is  required  by  association-accepting  DSAs  to  escape  unwanted  associations,  which, 
under  the  ROSE  protocol,  they  cannot  release.  In  all  other  cases  (association-initiating  DSAs  and  DUAs)  it 
may  be  preferable  (though  not  required)  to  escape  associations  using  UNBIND  rather  than  abort. 

The  aborting  DUA  or  DSA  may  optionaSly  use  the  user  Information  field  of  the  A-ABORT.  Such  Information, 
however,  is  only  meaningful  for  diagnostic  purposes  and  Its  use  is  not  covered  by  these  Agreements. 

1 1  Access  Control 

Guidelines  relating  to  access  control  for  the  t>ase  edition  of  the  Directory  standard  can  be  found  In  Annex 
F  of  the  Directory  Documents,  Part  2.  Specifications  for  access  control  in  the  extended  edition  of  the 
Directory  standard  are  found  in  DAM-1.3  to  ISO/SEC  9594-2.  DAM-1.3  to  SSO/IEC  9594-3,  and  DAM-1.3  to 
ISO/IEC  9594^. 

12  Test  Considerations 

This  clause  outlines  some  items  that  implementors  may  wish  to  consider  in  terms  of  testing  expectations; 
additionally,  future  conformance  testers  may  wish  to  consider  these  items  when  developing  tests. 

12.1    Major  Elements  of  Architecture 

One  important  aspect  of  testing  is  to  confirm  the  correct  behavior  of  DSAs  and  DUAs  with  respect  to  major 
elements  of  the  directory  architecture. 

Such  major  elements  include: 

a)  Conformance  Statement; 

b)  Distinguished  names  (e.g.,  name  resolution,  equivalence  of  various  forms); 

c)  Entries  and  Attributes  (e.g.,  accessibility  by  operations,  compliance  with  rules); 

d)  Handling  of  distributed  operations  (e.g.,  naming  contexts  and  knowledge); 

e)  Schemas: 

1)  Structure  rules  (e.g.,  storage  and  maintenance  of  structure  and  of  naming  rules); 

2)  Object  classes  and  sob-classes  (e.g.,  storage  and  extension  of  rules  for  object 
attributes); 
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3)  Attribute  types  (e.g.,  storage  arxJ  maintenance  of  syntax  classes  and  mies  for  multl  or 
single  valued  attributes); 

4)  Attribute  syntax  (e.g.,  nnaintenance  and  support  for  attribute  value  testing  and  matching, 
to  specification  for  a  defined  set  of  attribute  types); 

f)  Operations: 

1)  all  operations; 

2)  correct  function; 

3)  correct  result; 

4)  correct  responses; 

g)  Aliases  (e.g..correct  resolution,  error  responses); 

h)  Authentication  and  Access  Control  (e.g.,  limitation  of  modify  access); 

I)  ROSE  (e.g.,  correct  handling  of  invokes,  results,  rejects,  and  invol<e  ids); 

j)  ACSE  (e.g.,  association  establishment  /  refusal  for  invalid  application  contexts, etc.). 

12.2    Search  Operation 

Testing  of  support  for  filter  items  should  be  reasonable.  It  is  not  expected  that  DSAs  will  be  able  to  handle 
worst  case  testing  in  this  area. 


13  Errors 

This  clause  provides  clarification  of  the  semantics  of  various  operation  errors  and  implementation  guidelines 
on  their  usage. 


13.1    Permanent  vs.  Temporary  Service  Errors 

This  subclause  provides  some  clarification  regarding  the  usage  of  the  Service  Errors  busy,  unavailable,  and 
unwIllingToPerform. 

The  error  busy  is  particularly  transient.  It  is  returned  when  one  or  more  of  The  Directory's  internal  resources 
are  being  us^  to  their  capacity  and,  hence,  the  requested  operation  cannot,  for  the  moment,  be  performed. 
The  Directory  should  be  at>ie  to  recover  from  this  type  of  resource  depletion  after  a  short  while. 

The  error  unavailable  is  also  temporary  but  somewhat  less  transient.  It  indicates  that  The  Directory  (or  some 
part  of  it)ls  currently  unavailable  and  may  continue  to  t»e  unavailable  for  a  reasonably  long  period  of  time. 
For  example,  this  error  is  returned  when  a  given  DSA  is  functionally  disabled,  or  when  a  specific  part  of  the 
DIB  is  undergoing  reconfiguration. 


25 


Part  11  •>  Directory  Services  Protocois 


December  1992  (Stabie) 


The  error  unwilllngToPerlorm  has  a  permanent  connotation.  It  indicates  that  The  Directory  cannot  perform 
the  requested  operation  t)ecause  it  would  require  resources  beyond  Its  capacity.  For  example,  this  error  may 
be  retumed  by  a  DSA  If  satisfying  a  request  would  result  In  the  generation  of  an  APDU  in  excess  of  2**18  - 
1  octets. 

13.2    Guidelines  for  Error  Handling 

NOTE  -  The  error  handling  tables  indude  symptoms  and  situations  for  the  DISP  as  defined  In  the  forthcoming 
edition  of  the  OSI  Directory  standard. 

13.2.1  Introduction 

This  subclause  provides  a  recommended  mapping  of  error  situations  which  may  be  encountered  to  ROSE 
Rejects  or  to  the  errors  provided  in  the  DAP,  DSP,  and  DiSP  protocois  of  the  Directory  Documents. 

The  Directory  Documents  are  not  adequately  definitive  about  the  handling  of  errors.  In  this  document,  more 
explicit  guidelines  are  given. 

Error  situations  are  defined  by: 

a)  Symptom  (i.e., the  manner  In  which  the  error  was  detected); 

b)  Situation  (I.e.,  the  circumstance  or  phase  during  which  the  error  was  detected.  For  each  possible 
situation,  the  error-handling  procedure  needs  to  be  defined). 

13.2.2  Symptoms 

Table  10  describes  a  set  of  symptoms;  the  set  Is  not  necessarily  exhaustive.  Each  is  identified  by  a  title 
which  is  used  later  in  describing  error  actions.  The  title  used  for  each  symptom  Is  not  intended  to  imply  any 
particular  usage  in  a  particular  implementation. 

13.2.3  Situations 

Table  1 1  identifies  recognized  situations  within  which  particular  symptoms  may  give  rise  to  distinct  error  \ 
actions. 


13.2.4     Error  Actions  I 

Table  13  summarizes  specific  error  actions  for  each  possible  combination  of  symptom  and  situation. 
Symptoms  are  descrit}ed  In  13.2.2  and  situations  are  described  in  13.2.3. 

Each  entry  in  table  13  corresponds  to  the  symptom  In  the  left-most  column  and  the  situation  given  In  the  [ 
column  header.  Each  entry  may  specify:  i 

a)  a  specific  error  action.  The  error  action  Is  described  using  the  notation  shown  in  table  12;  i 
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b)  a  specific  error  action  arxi  a  relevant  note.  The  note  wUI  be  Indicated  by  a  number  enclosed  in 
parentheses.  The  notes  can  be  found  at  the  end  of  table  13; 

c)  only  a  relevant  note; 

d)  a  blank  (which  indicates  the  corresporxiing  combination  of  symptom  and  situation  Is  not 
meaningful  in  the  context  of  these  Agreements). 

The  entries  In  table  13  which  specify  a  specific  error  action  will  do  so  using  the  notation  shown  in  table  12. 
13.2.5  Reporting 

In  addition  to  the  use  of  error-reporting  services.  DSAs  should  implement  logging  services  to  assist  in 
management  of  the  Directory.  The  list  below  describes  classes  of  en-or  which  should  be  logged.Note  that 
the  list  is  not  necessarily  complete: 

a)  Errors  indicating  attempted  breaches  of  security; 

b)  En'ors  indicating  local  software  or  hardware  malfunction; 

c)  Errors  Indicating  malfunction  or  other  unacceptable  t>ehavior  on  the  part  of  the  invoker  of  an 
operatton; 

d)  Errors  Indicating  loss  of  chaining  service  by  another  DSA; 

e)  Error  conditions  that  would  t>e  difficult  to  diagnose  with  the  level  of  detail  supplied  over  the 
protocol; 

f)  Aborts  and  other  exceptional  communications  events. 
The  fomra  and  accessibility  of  any  such  logs  Is  for  further  study. 

14  Specific  Authentication  Schemes 

This  clause  kJentifies  authentiction  algorithms  for  use  in  Directory  authentication.  Infonnative  text  and  ASN.1 
definltkMis  describing  these  algorithms  appears  in  part  12  (Security).  Use  of  algorithms  other  than  those 
cited  in  this  clause  or  described  in  the  Directory  Documents  is  by  bilateral  agreement. 

14.1    Specific  Strong  Authentication  Schemes 

This  subclause  cites  one  alternative  to  the  RSA  digital  signature  scheme,  the  "EIGamal"  digital  signature 
scheme.  Future  contributions  may  result  in  other  alternatives  being  added  to  this  sut>clause. 

Implementors  may  choose  to  provide  digital  signature  capability  based  on  RSA,  EIGamal,  or  some  other 
scheme  appropriate  for  use  In  the  OSI  Directory  environment. 

It  should  be  noted  that  RSA  and  EIGamal  are  govemed  by  U.S.A.  patent  law. 
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14.1.1  EIGamal 

The  EIGamal  digital  signature  scheme  was  originally  descrit>ed  by  Taher  EIGamal  in  [ELGA85].  Part  12 
(Security)  of  these  agreements  contains  details  on  the  use  of  EIGamal,  including  an  informative  description 
of  the  scheme  using  the  notation  described  in  part  8  of  the  Directory  Documents  and  known  constraints  on 
algorithm  parameters. 


14.1.2     One-Way  Hash  Functions 

This  subclause  cites  alternative  one-way  hash  functions  for  use  in  Strong  and  Protected  Simple 
Authentication.  The  Security  SIG  continues  to  investigate  the  security  of  additional  one-way  hash  functions, 
and  the  Directory  Services  SIG  will  consider  the  applicability  of  these  hash  functions  to  Directory 
authentication. 

A  recent  development  in  this  area  is  the  citation  by  the  Security  SIG  of  RSA  MD4.  In  another  recent 
development,  the  two-pass  application  of  the  SNEFRU  algorithm  was  announced  by  Ralph  Merkte  to  have 
been  broken.  Future  study  of  MD4  and  other  contributions  may  result  in  other  additions  to  this  sutx^lause. 

At  the  present  time,  implementors  may  choose  to  provide  one-way  hash  functionality  based  on  MD2  or  some 
other  scheme  aplpropriate  for  use  in  the  OSI  Directory  environment. 

1 4.1 .2.1  SQUARE-MOD-N  Algorithm 

Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D  of  the  Directory 
Documents,  Part  8,  has  revealed  that  the  function  is  not  secure.  Its  use,  therefore,  is  discouraged. 

14.1.2.2  MD2  Algorithm 

MD2  is  a  one-way  hash  function  and  is  described  in  [RFC1 115]. 


14.1.2.3       Use  of  One-Way  Hash  Functions  in  Forming  Signatures 

MD2  may  be  used  to  form  digital  signatures  in  conjunction  with  RSA  or  EIGamal. 

14.1.3     ASN.1  for  Strong  Authentication  Algorithms 

This  subclause  defines  object  identifiers  assigned  to  authentication  algorithms.  The  definitions  take  the  form 
of  the  ASN.1  module,  "OIWAIgorithmObjectldentifiers." 
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OIWAlgorithinObjectldentifiers  (i80(l)  identi£ied-oraanization(3) 

oiw(14)  dssig(7)  oIWAlgorith]BObjectIdenti£iers(l)} 
DEFINITIONS 
BEGIN 

EXPORTS 

md2,  md2WithRSA,  elGeunal,  md2WithElGainal; 

IMPORTS 

authent i cat i onFr amewor k 

FROM  UsefulDefinitions  { joint-iso-ccitt  ds(5)  aK>dules(l) 

usef ulDef ini t ions ( 0 ) } 

ALGORITHM 

FROM  Authent icationFreuaework  authent icationFramework; 

—  categories  of  object  identifiers 

algorithm  OBJECT  IDENTIFIER         {iso(l)  identif ied-organization(3) 

oiw(14)  dssig(7)  aIgorithm(2)} 

encriptionAIgorithm  OBJECT  IDENTIFIER  {algorithm  l) 

hashAlgorthm  OBJECT  IDENTIFIER  {algorithm  2} 

signatureAlgorithm  OBJECT  IDENTIFIER  {algorithm  3} 

—  algorithms 

md2  ALGORITHM 

PARAMETER  NULL 

::=  {hashAlgorithm  1} 

md2WithRsa  ALGORITHM 
PARAMETER  NULL 
:;=  {signatureAlgorithm  1} 

elGamal  ALGORITHM 
PARAMETER  NULL 
::-  {encrypt ionAlgor it hm  1} 


md2WithElGamal  ALGORITHM 
PARAMETER  NULL 

{signatureAlgorithm  2} 

END  —  of  Algorithm  Object  Identifier  Definitions 
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14.2  Protected  Simple  Authentication 

Protecting  the  user's  distinguished  name  and  password  provides  greater  degrees  of  security  than  where 
passwords  are  not  protected. 

The  procedure  for  achieving  this  protection,  referred  to  as  protected  simple  authentication,  is  outlined  In  the 
Directory  Documents,  Part  8,  clause  5.3.  The  approach  by  which  protected  identifying  information  may  be 
generated  is  outlined  in  the  Directory  Documents.  Part  8,  clause  5.4.  For  the  purpose  of  these  agreements, 
h  and  f2  as  specified  in  the  Directory  Documents,  Part  8,  clause  5.4  are  identical  MD2  one-way  functions. 
The  algorithms  for  Implementation  of  the  MD2  one-way  function  are  described  In  [RFC1 1 1 5]  (see  D.3).  Note 
that  the  use  of  MD2  maybe  subject  to  licensing  agreement.  Use  of  other  algorithms  for  other  one-way 
functtons  Is  by  bilateral  agreement. 

User  A  generates  Protected2  as  specified  in  the  Directory  Documents,  Part  8,  clause  5.4.  Authentlcator2  Is 
then  conveyed  to  B  in  the  form  of  Simple  Credentials.  Table  14  shows  the  relationship  t>etween 
SimpleCredentialfields  and  the  elements  of  protected  simple  authentication  as  shown  in  figure  2  of  the 
Directory  Documents,  Part  8. 

14.3  Simple  Authentication 

There  are  two  major  classes  of  authentication  supported  by  the  Directory  (i.e.,  simple  and  strong 
authentication).  Simple  authentication  is  t>ased  on  a  password  being  passed  between  the  two  associated 
entitles  (e.g.,  between  a  Directory  User  and  a  DUA,  or  between  two  DSAs).  in  the  case  of  Interaction 
between  a  Directory  User  and  a  DUA,  the  password  is  compared  in  some  way  with  the  password  attribute 
in  the  user's  entry  in  the  Directory,  in  the  case  of  interaction  between  two  DSAs,  this  cannot  be  done  since 
the  DSA  object  dass,  as  defined  in  the  Directory  Documents  (Part  7,  clause  6.14)  does  not  contain  a 
password  attribute. 

To  fecilitate  simple  authentication  between  DSAs.it  is  recommended  that  a  DSA  have  local  access  to  a  list 
of  one  or  more  known  DSAs,  with  a  copy  of  each  known  DSA's  password.  Maintenance  of  that  information 
Is  done  through  the  use  of  bilateral  agreements  between  DSA  administrators. 
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Part  11  -  Directory  Services  Protocols  December  1992  (Stable) 


Table  1  -  Pragmatic  constraints  for  selected  attributes 


Attribute  Type 

Content 

Constraints 

rrirnary 
Source 

Notes 

Aliased  Object  Name 

Distinguished 
Name 

Note  3 

Business  Category 

T.61  or  Printable 
String 

ub-business- 
category  128 

CCITT 
X.520 

Common  Name 

T.61  or  Printable 
String 

ub-common-  name 
64 

CCITT 
X.520 

Country  Name 

Printable  String 

2 

ISO  3166 

Description 

T.61  or  Printable 
String 

ul>description  1024 

CCITT 
X.520 

About  1  screen  full 

Destination  Indicator 

Printable  String 

ub-destination- 
indicator  128 

CCITT 
X.520 

Facsimile  Telephone 
Number 

Facsimile 

Telephone 

Number 

ub-telephone-numb 
er32 

CCITT 
X.520 

Optionally  includes 
Q3  non-basic  pa- 
rameters (Upper 
bounds  ffs) 

International  ISDN 
Number 

Numeric  String 

ub-isdn-address  16 

CCITT 
X.520 

C.I 64  Internarl 
ISDN  Number 

Knowledge 
Information 

T.61  or  Pnntable 
String 

1024 

OIW 

About  1  screen  full 

Locality  Name 

T.61  or  Printable 
String 

uk>-locality-name 
128 

UUITT 
X.520 

Member 

Distinguished 
Name 

Note  3 

Object  Class 

Object  Identifier 

256  octets 

OIW 

Organization  Name 

T.61  or  Printable 
String 

ub-organization-na 
me  64 

CCITT 
X.520 

Organizational  Unit 
Name 

T.61  or  Printable 
String 

ub-organizational- 
unit-  name  64 

CCITT 
X.520 

Owner 

Distinguished 
Name 

Note  3 

Physical  Delivery 
OfficeName 

T.61  or  Printable 
String 

ut>-physical-office-n 
ame  128 

CCITT 
X.520 
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Table  1  -  Pragmatic  con»tralnt«  for  selected  attributes  (continued) 


1  Attribute  Typ« 

Content 

Constraints 

Primary 
Source 

Notes 

1  Post  Offioe  Box 

T.61  or.  Printable 
String 

uk>-p08t-office-box 
40 

CCITT 
X.520 

Postal  Address 

Postal  Address 

ut>-postal-lin66 
uk>-postal-8tring30 

CCITT 
X.520 

UPU 

Postal  Code 

T.61  or  Printable 
String 

uk}-postal-code  40 

CCITT 
X.520 

Presentation 
Address 

Presentation 
Address 

224  octets 

NIST 

Note  2(page  ?), 
ISO  7498.3  & 
X.200 

Registered  Address 

Postal  Address 

ub-po8tal-line6 
ub-postal-string30 

CCITT 
X.520 

1  Role  Occupant 

Distinguished 
Name 

Note  3 

Search  Guide 

Guide 

256 

OIW 

See  Also 

Distinguished 
Name 

Note  3  (page  ?) 

Serial  Number 

Printable  String 

ut>-8erial-numt>er  64 

CCITT 
X.520 

State  or  Province 
Name 

T.61  or  Printable 
String 

ub-state-name  128 

CCITT 
X.520 

Street  Address 

T.61  or  Printable 
String 

ub-street-address 
128 

CCITT 
X.520 

Supported 
Application  Context 

Object  Identifier 

256 

OIW 

Surname 

T.61  or  Printable 
String 

ub-surname  64 

CCITT 
X.520 

Telephone  Numt)er 

Printable  String 

ukvtelephone-numb 
er32 

CCITT 
X.520 

E.I  23 
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Table  1  -  PragmaMc  constraints  tor  selected  attribute*  (concluded) 


AnribuleType 

Content 

Constraints 

Primary 
Source 

Notes  1 

Teletex  Terminal 
kJentHier 

Teletex  Terminal 
Ider^tifier 

uk)-teletex-terminaM 
d  1024 

ccnr 

x.520 

Optionally  includes  1 
Teletex  non-t>asic 
parameters  (upper 
bound  ffe) 

Telex  NumtMT 

Telex  Number 

ub-telex-numt)er14 
ut>-country-oode4 
ut>-an8w«rt)ack  8 

ccnr 

x.520 

Contains  sequence 
of  telex  nurrtber, 
country  code,  and 
answerisack 

TMe 

T.61  or  Printat)le 
String 

ul>title64 

CCITT 
X.520 

User  Password 

Octet  String 

ut>-u8er-pa8sword 
128 

CCITT 
X.520 

Allow  long  pass- 
words generated  1 
by  machine  | 

X.121  Address 

Numeric  String 

ub-x121-address  15 

CCITT 
X.520 

X121  1 

NOTES 

1  The  pragmatic  constraints  of  these  parameters  are  defined  in  other  standards.  We  will 
accommodate  these  values  in  our  pragmatic  constraints. 

2  Presentation  address  is  composed  of  "X"  NSAP  addresses,  and  three  selectors,  (20X  -i-  32 
•t-  16    16).  e.g.,  if  X=  1,  this  would  be  84.  These  numbers  are  based  on  the  most  recent 
implementors'  agreements.  With  8  NSAP  addresses  this  value  is  224. 

3  Pragmatic  constraints  are  only  applied  to  the  individual  components  of  Distinguished  Name 
as  defined  in  the  Directory  Documents.  Part  2.  Not  all  comportents  of  a  DN  will  necessarily  be 
understood  by  an  implementation. 

4  Implementors  should  be  aware  that  constraints  on  Postal  Address  may  not  be  sufficient  for 
some  markets. 
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 Table  2  -  Directofy  accest  service  support 


Support  Classification 

Operations  and  Errors 

DUA 

DSA 

Comments 

-  BIND  and  UNBIND  - 

DirectoryBind 

r 

r 

DirectoryUnbind 

r 

r 

-  OPERATIONS  - 

-  READ  OPERATIONS- 

n 

r 

Cornpar6 

n 

r 

Abandon 

n 

r  (note  2) 

1  If* 

n 

r  (note  1) 

WOCU  Wl  1 

n 

r  (note  1) 

-  MODIFY  OPERATIONS  - 

AddEntry 

n 

r 

RemoveEntry 

n 

r 

ModifyEntry 

n 

r 

ModifyRDN 

n 

r 

-  ERRORS  - 

Abandoned 

(note  4)r 

AbandonedFailed 

(note  4)r 

AttributeError 

(note  4)r 

NameError 

(note  4)r 

Referral 

(note  4) 

r(note  3) 
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Part  11  -  Directory  Services  Protocols  December  1992  (Stable) 
 Table  2  -  Directory  access  •ervlce  support  (concluded) 


Support  Classification 

Operations  and  Errors 

DUA 

DSA 

Comments 

SecurrtyError 

(note  4) 

r 

ServiceError 

(note  4) 

r 

UpdateError 

(note  4) 

4 

NOTES 

1  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  tfie 
policies  of  some  centralized  DSAs  may  be  tfiat  such  operations  will  not  be  performed.  For 
these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError  with  the 
"unwillingToPerform"  Service  Problem. 

2  Reference  Directory  Documents,  Part  3,  clause  9.3.6 

3  Centralized  DSAs  would  not  generate  referrals. 

4  See  EntrytnformationSelection  information  under  Common  Data  Types  (table  3,  Part  6) 
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Table  3  -  DAP  protocol  support 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

-  BIND  and  UNBIND  - 

DirectoryBInd 

DIrectoryBlndArgument 

M 

IVI 

s 

credentials 

0 

s 

simple 

0 

s 

name 

G 

s 

validity 

0 

0 

password 

G 

s 

strong 

■ 

0 

0 

See  Strong  Authentication 
Protocol  Conformance  Profile  for 
requirements  when  strong 
authentication  is  supported. 

externalProcedure 

0 

0 

versions 

0 

s 

Supported  value:  v1988 

DirectoryBindResult 

s 

G 

credentials 

0 

G 

Shall  be  the  same  CHOICE  as  in 
DirectoryBindArgument. 

simple 

0 

G 

name 

S 

G 

validity 

0 

0 

password 

0 

0 

strong 

0 

0 

See  Strong  Authentication 

Protocol  Conformance  Profile  for 
requirements  when  strong 
authentication  is  supported. 

externalProcedure 

0 

0 

versions 

s 

0 

Supported  value:  v1988 
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Part  11  -  Directory  Services  Protocols                              December  1992  (Stable) 
 Table  3  -  DAP  protocol  support  (continued)  


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

DirectoryBlndError 

S 

G 

versions 

S 

0 

Supported  value:  v1988 

Sen/iceProblem 

S 

G 

Supported  value:  unavailable 

SecurityProblem 

S 

G 

Supported  values: 

inappropriateAuthentication, 

invalidCredentials 

DIrectoryUnbind 

The  DIrectoryUnbind  has  no 
arguments. 

-  OPERATIONS.  ARGUMENTS  AND  RESULTS  - 

-  READ  OPERATIONS  - 

Read 

ReadArgument 

M 

S 

object 

M 

S 

selection 

0 

S 

See  note  2 

CommonArguments 

0 

S 

ReadResutt 

S 

G 

entry 

S 

M 

CommonResults 

S 

G 

Compare 

CompareArgument 

M 

S 

object 

M 

S 

purported 

M 

S 

CommonArguments 

0 

S 

CompareResult 

S 

G 
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Table  3  -  DAP  protocol  support  (continued) 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

DistinauishedName 

S 

G 

S 

M 

fromPntn/ 

S 

G 

S 

G 

MUcuiumi 

AliandonAraufiMnt 

M 

S 

invoKetu 

M 

S 

AbandonResuh 

S 

G 

•  SEARCH  OPERATIONS  - 

List 

ListArgument 

M 

S 

otiject 

M 

S 

CommonArguments 

0 

S 

S 

G 

listlnfb 

S 

G 

DIstinguishedName 

S 

G 

subordinates 

S 

M 

Rel.Di8tinguishedName 

S 

M 

For  the  case  wtiere  subordinates 

is  empty  set,  RON  is  at)sent. 

aiiasEntry 

S 

G 

fromEntry 

S 

G 

partiaiOutcomeQuaiifier 

S 

G 

CommonResults 

S 

G 

UncorreiatedListlnfo 

S 

G(0) 

f 

I 
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December  1992  (Stable) 


Table  3  -  DAP  protocol  support  (continued) 


1 

Support  Classification 

1 

1  Protocol  Element 

DUA 

DSA 

Comments 

1  ListResult 

S 

G 

See  note  1  for  additional 
information  related  to  the  DSA 
support  classification. 

Search 

SearchArgument 

M 

S 

baseObject 

M 

s 

subset 

0 

s 

filter 

searchAliases 

0 

S 

0 

S 

selection 

0 

s 

CommonArguments 

0 

S 

SearchResult 

s 

G 

searchinfo 

S 

G 

DistinguishedName 

S 

G 

entries 

S 

M 

partialOutcomeQualifier 

S 

G 

CommonResults 

S 

G 

uncorrelatedSearchinfo 

S 

G(0) 

SearchResult 

S 

G 

partialOutcomeQualifier 

S 

G 

limitProblem 

S 

G 

unexplored 

S 

G 

unavailableCriticalExt 

S 

0 

-  MODIFY  OPERATIONS  - 

AddEntry 

AddEntryArgument 

M 

S 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Prr^tfw%l  PI  Am  Ant 

DUA 

DSA 

v^vi  1 II 1  Id  iio 

object 

M 

S 

entry 

M 

S 

CommonArgument 

0 

s 

AddEntryResult 

s 

G 

RemoveEntry 

RemoveEntryArgument 

M 

s 

object 

M 

s 

CommonArguments 

0 

s 

RemoveEntryResult 

s 

G 

ModifyEntry 

ModifyEntryArgument 

M 

s 

object 

M 

s 

changes 

M 

s 

At  least  one  entry  modification 
must  be  supported. 

addAttribute 

0 

S 

removeAttribute 

0 

s 

0 

s 

removeValues 

0 

s 

CommonArguments 

0 

s 

ModifyEntryResult 

S 

G 

ModifyRDN 

ModifyRDNArgument 

M 

S 

object 

M 

S 

newRDN 

M 

S 

deleteOldRDN 

0 

S 

CommonArguments 

0 

G 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

ModifyRDNResult 

S 

G 

-  ERRORS  AND  PARAMETERS  - 

Absndoned 

AbandonFailed 

problem 

S 

M 

operation 

S 

M 

AttributaError 

object 

S 

M 

problems 

S 

M 

Min.  1  error(See  Directory 
Documents.  Part  3,  subclause 
12.4.2.2) 

type 

S 

M 

value 

S 

G 

NameError 

problem 

S 

M 

matched 

S 

M 

Referral 

candidate 

S 

G 

SecurityError 

problem 

S 

M 

Sen/iceError 

problem 

S 

M 

UpdateError 

problem 

S 

M 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

1 

Protocol  Element 

DUA 

DSA 

Lom  merits 



ModlfyRDNResult 

S 

Q 

•  ERRORS  AND  PARAMETERS  - 

B  Abandoned 

AbandonFailed 

problem 

S 

M 

operation 

s 

M 

AttributeEn-or 

object 

s 

M 

prot}lem8 

s 

M 

Min.  1  error(See  Directory 

Documents,  Part  3,  subclause 
12.4.2.2) 

type 

s 

M 

value 

s 

G 

NameError 

D  proDiem 

s 

M 

matched 

s 

M 

Referral 

candidate 

s 

G 

SecurityError 

problem 

s 

M 

ServiceError 

1  problem 

s 

M 

1  UpdateError 

y  problem 

s 

M 

i 
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Table  3  -  DAP  protocol  support  (continued) 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  /  RESULTS  - 

ijommonArgumerus 

ServlceControls 

U 

c 
o 

SecurityParameters 

U 

c 
o 

See  subclause  8.8. 

certification-path 

U 

c 
o 

name 

U 

c 
o 

time 

r\ 
\J 

c 
o 

random 

r\ 
U 

c 
o 

target 

U 

e 
o 

requestor 

r\ 

U 

o 
o 

uperaiionrrogress 

r\ 

yj 

b  (U) 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

0 

S 

aliasedRDNs 

0 

S(0) 

extensions 

0 

s 

identifier 

M 

s 

critical 

0 

s 

item 

M 

s 

CommonResults 

SecurityParameters 

0 

G(0) 

See  subclause  8.8. 

certification-path 

0 

G 

name 

0 

G 

time 

0 

G 

random 

0 

G 

target 

0 

G 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

performer 

0 

G(0) 

aliasDereferenced 

0 

G 

-  COMMON  DATA  TYPES  - 

1  ServlceControls 

options 

r\ 
\J 

e 
o 

priority 

U 

e 
o 

timeUmit 

U 

c 
o 

sizeLimit 

o 

s 

scopeOfReferral 

U 

o 
o 

EntrytnformationSelection 

attributeTypes 

0 

s 

allAttributes 

0 

s 

Must  support  at  least  one  of  the 
CHOICE. 

select 

U 

o 
o 

infoTypes 

0 

s 

Entrylnformation 

DistinguishedName 

s 

M 

fromEntry 

s 

G 

SET  OF  CHOICE 

s 

G 

AttributeType 

s 

G 

Attribute 

s 

G 

Filter 

Must  support  at  least  one  of  the 
CHOICE. 

item 

0 

S 

and 

0 

S 

or 

0 

S 
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 Table  3  -  DAP  protocol  support  (continued)  


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

not 

0 

S 

Filtefttem 

equality 

0 

S 

substrings 

0 

S 

tvDe 

M 

S 

Strings 

M 

S 

initial 

0 

S 

Must  support  at  least  one  of  the  1 
CHOICE.  1 

any 

u 

o 
o 

1 

final 

greaterOrEqual 

0 

U 

s 

c 
o 

1 
1 

lessOrEquai 

0 

S 

1 

present 

U 

c 
o 

1 

approxImateMatch 

o 

s 

1 

SecurityParameters 

0 

0 

See  sut}clause  8.8.  1 

certification-path 

0 

s 

name 

0 

s 

time 

0 

s 

random 

0 

s 

target 

0 

s 

ContinuationReference 

targetObject 

0 

M 

aliasedRDNs 

0 

G 

OperationProgress 

0 

M 

nameResolutionPhase 

0 

M 

nextRDNToBeResolved 

0 

G 
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Part  11  -  Directory  Services  Protocols  December  1992  (Stable) 
 Table  3  -  DAP  protocol  tupport  (concluded) 


Support  Classification 

1 

Protocol  Element 

DUA 

DSA 

N^Vrg  1  II  1  Iwl  lEV  ■ 

rdnsResoh/ed 

0 

G 

AccessPoInt 

0 

M 

AccessPoint 

Name 

0 

M 

PresentatlonAddress 

0 

M 

pSelector 

0 

G 

sSelector 

0 

G 

tSelector 

0 

G 

nAddress 

0 

M 

NOTES 

1  As  perfomiance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DSAs  may  be  that  such  operations  will  not  be  performed.  For  | 
these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError  with  the  1 
"unwillingToPerform"  Service  Problem.  1 

2  See  EntrylnfbrmationSelection  information  under  Common  Data  Types  (table  3,  part  6) 
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Table  4  -  Directory  system  service  support 


Support  Classification 

Operations  and  Errors 

Request 

Response 

Comments 

-  BIND  and  UNBIND  - 

DSABind 

n(notes  1,2) 

r 

DSAUnbind 

n(notes  1,2) 

r 

-  OPERATIONS  - 

OPERATIONS  - 

ChainedRead 

n(notes  1,2) 

ChainedCompare 

n(notes  1,2) 

chainedAbandon 

n(note  1) 

-  CHAINED  SEARCH 
OPERATIONS  - 

ChainedList 

n  (note  1) 

ChainedSearch 

n  (note  1) 

-  CHAINED  MODIFY 
OPERATIONS  - 

ChainedAddEntry 

n  (note  1) 

r 

ChainedRemoveEntry 

n  (note  1) 

r 

ChainedEntry 

n  (note  1) 

ChainedModifyRDN 

n  (note  1) 

-  ERRORS  - 

Abandoned 

n(note  1) 

Abandonfailed 

n(note  1) 

AttributeError 

n(note  1) 

NameError 

n(note  1) 

DSARefferal 

n(note  1) 

SecurityError 

n(note  1) 

SeviceError 

n(note  1) 

UpdateError 

n(note  1) 

NOTES 

1  Necessary  when  supporting  the  chained  nnode  of  interaction. 

2  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication.  This 
requirement  is  distinct  from  support  for  chained  mode  of  interaction. 
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Table  5  -  DSP  protocol  support 


Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

-  BIND  and  UNBIND  - 

UoADina 

uirecioryDinQMryurnorii 

M 

S 

CieuanileUS 

G 

S 

simple 

G 

S 

name 

G 

S 

validity 

0 

0 

password 

G 

S 

strong 

0 

0 

See  Strong  Authentication 

Protocol  Conformance  Profile 
for  requirements  when  strong 
authentication  is  supported. 

externalProcedure 

0 

0 

versions 

G 

S 

Supported  value:  v1988 

DSABindResult 

S 

G 

credentials 

S 

G 

Shall  be  the  same  CHOICE 
as  in  DirectoryBindArgument. 

simpio 

S 

G 

name 

S 

G 

validity 

0 

0 

password 

S 

G 

strong 

0 

0 

See  Strong  Authentication 

Protocol  Conformance  Profile 
for  requirements  when  strong 
authentication  is  supported. 

externalProcedure 

0 

0 

versions 

S 

G 

Supported  value:  v1988 

DirectoryBindError 

S 

G 

versions 

S 

G 

Supported  value:  v1988 

ServiceProblem 

S 

G 

Supported  values:  busy  and 
unavailable. 

SecurityProblem 

S 

G 

Supported  values: 

inappropriate  Authentication, 
invalidCredentials. 

DSAUnbind 

The  DSAUnbind  has  no 
arguments. 
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Table  5  -  DSP  protocol  support  (continued)  


Protocol  Element 

Support  Classification 

Comments 

Request 

Response 

-  OPERATIONS,  ARGUMENTS 

AND  RESULTS  - 

-  CHAINED  READ  OPERATIONS  - 

ChainedRead 

ChainingArgument 

M 

S 

ReadArgument 

M 

S 

object 

M 

S 

selection 

G 

S 

CommonArguments 

G 

S 

ChalningResult 

S 

M 

ReadResult 

S 

M 

entry 

s 

M 

CommonResults 

s 

G 

ChainedCompare 

ChainingArgument 

M 

S 

CompareArgument 

M 

S 

object 

M 

S 

purported 

M 

S 

CommonArguments 

G 

S 

ChalningResult 

S 

M 

CompareResuh 

S 

M 

DistinguishedName 

S 

G 

matched 

S 

M 

fromEntry 

S 

G 

CommonResults 

S 

G 

ChainedAbandon 

AbandonArgument 

M 

S 

invokeld 

M 

S 

AbandonResult 

S 

G 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

-  CHAINED  SEARCH 
OPERATIONS  - 

ChainedList 

ChainingArguments 

M 

S 
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 Table  S  -  DSP  protocol  support  (continued) 


1 

Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

ListArgument 

M 

IVI 

e 

object 

M 

u 

Ck)mmonArguments 

r» 
u 

e 
o 

ChalningResults 

c 

d 

M 

ListResult 

C 

o 

M 

listlnifb 

c 
o 

O 

DistingulshedName 

c 
o 

V3 

sutx>rdlnate8 

C' 

o 

M 

Rel.DlstingulshedName 

c 
o 

M 

aliasEntry 

e 
o 

(a 

fromEntry 

partialOutcomeQualifier 

o 

CommonResults 

s 

G 

uncorrelatedListlnfo 

c 
o 

ListResult 

c 
o 

ft 
V3 

ChainedSearch 

SearchArgument 

M 

M 

C 

o 

baseObject 

M 

s 

sugset 

o 

s 

filter 

o 

s 

searchAliases 

\3i 

s 

selection 

G 

s 

CommonArguments 

G 

8 

ChalningResults 

S 

M 

SearchResult 

S 

M 

Searchinfo 

S 

M 

DistingulshedName 

S 

G 

entries 

S 

M 

partialOutcomeQualifier 

S 

G 

CommonResults 

S 

G 

uncorrelatedSearchinfo 

S 

G 

SearchResult 

S 

G 

partialOutcomeQualifier 

S 

G 

limitProblem 

S 

G 

... 
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Table  5  -  DSP  protocol  support  (continued) 


Protocol  Element 

Support  Classification 

Comments 

Request 

Response 

unexplored 

S 

G 

unavailableCritlcalExt 

S 

G 

-  CHAINED  MODIFY 

OPERATIONS  - 

ChainedAddEntry 

ChainingArguments 

M 

Q 
O 

AddEntryArgument 

M 

C 
O 

object 

M 
M 

o 
o 

entry 

M 

Q 

CommonArguments 

V3 

c 
o 

ChainlngResults 

e 
o 

M 

AddEntryResults 

c 

M 
M 

ChainedRemoveEntry 

ChainingArguments 

ft  J 

e 
o 

RemoveEntryArgument 

M 

Q 

o 

object 

ft  J 

M 

o 

o 

CommonArguments 

f\ 
o 

b 

ChainlngResults 

c 
o 

M 

M 

RemoveEntryResuK 

c 
o 

hil 
M 

ChainedModifyEntry 

ChainingArguments 

M 

M 

C 

ModifyEntryArgument 

M 
IVl 

object 

ft  1 

M 

Q 

changes 

M 

S 

addAttribute 

G 

S 

removeAttribute 

G 

S 

addValues 

G 

8 

removeValues 

G 

S 

CommonArguments 

G 

S 

ChainlngResults 

S 

M 

ModifyEntryResult 

S 

M 

ChainedModifyRDN 

ChainingArguments 

M 

S 

ModifyRDNArgument 

M 

S 

object 

M 

S 
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 Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

1 

Request 

Response 

1 

xA^i  1 11  iioi  iio  n 

 __j 

newRDN 

M 

s 

deleteOldRDN 

G 

S 

\ 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

ModifyRDNResuit 

s 

M 

•  ERRORS  and  PARAMETERS  • 

Abandoned 

AbandonFailed 

problem 

s 

M 

operation 

s 

M 

AttributeError 

Min.l  error  (see  Directory 
Documents,  part  3, 
subclause  12.4.2.2) 

object 

s 

M 

problems 

s 

M 

problem 

8 

M 

type 

S 

M 

value 

S 

G 

NameError 

problem 

S 

M 

matched 

s 

M 

DSARefferal 

ContinuatlonReference 

c 
o 

M 

contextPrefix 

S 

G 

SecurityError 

problem 

s 

M 

Sen/lceError 

s 

G 

For  Directory  operations 

problem 

s 

M 

UpdateError 

s 

G 

problem 

s 

M 

•  COMMON  ARGUMENTS  / 

RESULTS  - 

CommonArguments 

Sen^lceControls 

G 

S 

SecurityParameters 

0 

S 

see  subclause  8.8. 

I 
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 Table  5  -  DSP  protocol  support  (continued) 


1 

1  Protocol  Element 

Support  Classification 

Comments 

Request 

Response 

1  requestor 

G 

s 

1  Oper£ttionProgress 

G 

s 

nameResolutlonPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

aliasedRDNs 

G 

s 

extensions 

G 

s 

Identifier 

M 

s 

critical 

G 

s 

Item 

M 

s 

CommonResuits 

SecurityParameters 

s 

0 

See  subclause  8.8. 

requestor 

s 

G 

aliasDereferenced 

S 

G 

-  COMMON  DATA  TYPES  - 

Sen/iceControls 

options 

G 

s 

priority 

G 

s 

timeUmIt 

G 

s 

sizeUmIt 

G 

s 

scopeOfReferral 

Q 

s 

EntrylnfbrmationSelection 

attributeTypes 

G 

s 

allAttributes 

G 

s 

select 

G 

s 

InfbTypes 

G 

S 

Entrylnfbrmation 

DistinguishedName 

S 

M 

fromEntry 

S 

G 

SET  OF  CHOICE 

S 

G 

AttributeType 

S 

G 

Attribute 

S 

G 

Filter 

item 

G 

S 

and 

G 

S 

or 

G 

S 

not 

G 

S 
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Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

1 

Protocol  cisment 

Request 

Response 

uornrnents  i 

f- 

1  Fiherltem 

equality 

G 

S 

substrings 

G 

s 

1 

type 

G 

s 

1 

strings 

G 

s 

Initial 

G 

s 

any 

G 

s 

final 

G 

s 

greaterOrEqual 

G 

s 

lessOrEqual 

G 

s 

present 

G 

s 

approximateMatch 

G 

s 

-  COMMON  DATA  TYPES  FOR 

DISTRIBUTED  OPERATION  - 

ChainingArguments 

originator 

G 

s 

targetObject 

G 

s 

operationProgress 

Ui 

o 
o 

nanmeResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

tracelnfbrmation 

M 

s 

aliasDereferenced 

G 

s 

aliasedRDNs 

G 

s 

retumCrossRefs 

G 

s 

See  Directory  Documents, 
Part  4,  subclause  10.4.1 

referenceType 

G 

s 

Domainlnfo 

0 

0 

timeUmit 

G 

s 

SecurityParameters 

0 

s 

See  note  1  regarding  the 

support  classification  for 
Request.  Also  see  subclause 
8.8 

1  ChainingResults 

1  Info 

0 

0 

H  crossReferences 

S 

G 
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Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

SecurityParameters 

S 

0 

See  note  1  regarding  the 
support  classification  for 
Response.  Also  see 
subclause  8.8 

CrossReference 

cxjntextPrefix 

c 
o 

See  Directory  Documents, 
Part  4,  subclause  12.4.2.2 

accessPoint 

s 

M 

Tracelnformation 

Traceltem 

M 

S 

Traceltem 

dsa 

M 

S 

targetObject 

G 

S 

operationProgress 

M 

S 

nameResolutionPhase 

M 

S 

nextRDNToBeResolved 

G 

S 

ContinuationReference 

targetObject 

S 

M 

aliasedRDNs 

S 

G 

operationProgress 

S 

M 

nameResolutionPhase 

S 

M 

nextRDNToBeResolved 

S 

G 

rdnsResolved 

S  ' 

G 

referenceType 

S 

G 

AccessPoint 

S 

M 

AccessPoint 

Name 

S 

M 

PresentationAddress 

S 

M 

pSelector 

S 

G 

sSelector 

S 

G 
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Table  5  -  DSP  protocol  support  (concluded) 


Protocol  Element 


Support  Classification 


Request 


Response 


Comnnents 


tSelector 
nAddress 


G 
M 


NOTES 

1  The  support  classification  is  G  when  supporting  the  chained  mode  of  interaction. 

2  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication.  This 
requirement  is  distinct  from  support  for  chained  mode  of  interaction. 


Table  6  -  DAP  Support  for  Digital  Signature  Protocol  Conformance  Profile. 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

•  COMMON  ARGUMENTS  / 

RESULTS  - 

CommonArguments 

SecurityParameters 

certification-path 

G 

S 

name 

G 

S 

time 

G 

S 

random 

G 

S 

target 

G 

S 

requestor 

G 

S 

CommonResults 

SecurityParameters 

S 

G 

performer 

S 

G 
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 Tabte  7  -  DSP  support  for  digital  signature  protocol  conformance  profile 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

•  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

SecurityParameters 

certification-path 

G 

S 

name 

G 

S 

G 

S 

random 

G 

S 

target 

G 

S 

requestor 

G 

S 

CommonResults 

SecurityParameters 

G 

S 

performer 

0 

G 
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Table  8  -  DAP  support  for  strong  authentication  protocol  conformance  proflla 


-~  '  

Protocol  Element 

Support  Classification 

1 

Comments  H 

DUA 

DSA 

DirectoryBindArgument 

M 

S 

credentials 

G 

s 

simple 

G 

s 

name 

G 

s 

validity 

G 

s 

password 

G 

s 

strong 

certifi^ttion-path 

G 

s 

bind-token 

G 

s 

externalProcedure 

0 

0 

versions 

0 

s 

DirectoryBindResult 

o 
o 

credentials 

s 

G 

simple 

s 

G 

name 

s 

G 

validity 

s 

G 

password 

s 

G 

strong 

s 

G 

certification-path 

s 

G 

bind-token 

s 

G 

externalProcedure 

0 

0 

versions 

s 

0 
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Table  9  -  DSP  support  for  strong  authentication  protocol  conformance  profile 


Protocol  Element 

Support  Classification 

Comments 

uirectOiyDinuAryurneru 

M 

s 

creuenncus 

G 

s 

simDie 

G 

s 

1 ICU  1  lO 

G 

s 

validitv 

G 

s 

G 

s 

1 
1 

a  fitrona 

M                              Wlil  ^^1  Is4 

H  cdrtific3tion*pdtli 

G 

s 

H  bind-tokfin 

G 

s 

11  fiKtamalProcfidura 

0 

0 

i                vol  OIUI  lO 

0 

s 

L/iiocioryDiriijnosuii 

S 

G 

credentials 

S 

G 

simple 

S 

G 

name 

S 

G 

validity 

S 

G 

password 

S 

G 

strong 

S 

G 

certification-path 

S 

G 

bind-token 

S 

G 

externalProcedure 

0 

0 

versions 

S 

0 
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Table  10  -  Error  symptoms 


Symptom 

Description 

E  ACCESS 

The  initiator  has  insufficient  access  rights  to  carry  out  this  operation. 

E_ADMIN_UMIT 

The  Directory  has  reached  some  limit  set  by  an  administrative  authority, 
and  no  partial  results  are  available  to  return  to  the  user. 

E_AUAS_DEREF 

One  of  three  situations  exists: 

1  An    alias    has    been    encountered    while  a 
previous  alias  was  being  dereferenced,  or 

2  a  name  contained  an  alias  plus  one  or  more 
additional       RDNs       when  the 
dontDereferenceAliases  service  control  was 
being  used,  or 

3  the  mme,    supplied   in  an  operation  that 
precludes  alias      dereferencing,  contained 
an  alias  plus  one  or  more  additional  RDNs. 

E_ALIAS_LOOP 

During  a  whole-subtree  search  operation,  an 
alias  has  been  encountered  which  would  lead  to 
a  loop  (i.e.,  the  alias  points  to  an  entry 
which  is  superior  to  entries  which  have 
already  been  evaluated  in  carrying  out  the 
search) . 

E_ALIAS_PROBLEM 

An  alias  has  been  encountered,  but  the  entry  to 
vrtiich  it  points  does  not  exist. 

E_ARG_BOUNDS 

The  argiunent  does  not  comply  with  pragmatic 
constraints  (defined  locally  or  by  functional 
standards ) . 

i 
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Table  10  •  Error  symptoms  (continued) 


Symptom 

Description 

E_ARG_SYNTAX 

An  operation  argument  either  has  incorrect 
ASN.l  encoding  or  correct  ASN.l  encoding,  but 
does  not  comply  to  the  syntax  as  defined  in  the 
Directory  Documents. 

NOTES 

1  Within  BindArgument,  additional  elements  are  pennitted,  to 
allow  future  extensions,  and  do  not  create  an  error  situation. 

2  Errors  within  attribute  values  are  not  included  in  this 
codification  (see  E  ATT  SYNTAX). 

E_ARG_VIOL 

An  operation  argument  has  correct  syntax,  but 
it  violates  additional  rules  and  constraints 
levied  by  the  Directory  Documents  (e.g.,  use  of 
a  Priority  integer  value  whose     meaning  is 
undefined) . 

NOTES 

1  Within  a  Relative  Distinguished  Name,  having  two  AVAs  of 
the  same  attribute  type  is  an  error  which  is  covered  by 

E  ON,  and  not  by  E_ARG_VIOL 

2  Errors  within  attribute  values  are  not  included  in  this 
codification  (see  E  ATT  SYNTAX). 

E_ATT_BOUNDS 

An  attribute  value  does  not  comply  with  bounds 
specified  either  by  the  Directory  Documents  or 
by  functional  standards. 

E_ATT_OR_VALUE_EXI STS 

Within  an  entry,  an  attribute  or  attribute 
vaxue  axreaay  exists,  causing  an  error 
situation. 

E_ATT_SYNTAX 

An  attribute  value  either  has  incorrect  ASN.l 
encoding  or  it  has  correct  ASN.l  encoding  but 
does  not  comply  with  the  ASN.l  encoding  defined 
by  the  attribute  type. 

E_ATT_VALUE 

An  attribute  value,  although  of  correct  ASN.l 
encoding,  and  conformant  with  the  syntax 
defined  for  the  attribute  type,  is  not 
compliant  with  other  rules  (e.g.,  a  non-ISO 
3166  country  name  encoding). 

E_ACCESS 

The  initiator  has  insufficient  access  rights  to 
carry  out  this  operation. 

E_AUTHENTICATION 

The  authentication  offered  does  not  match  that 
required  by  the  object  being  authenticated. 
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Table  10  -  Error  symptoms  (continued) 


1  Symptom 

Description  j 

E_BUSY 

The  DSA  is  unable  to  handle  this  operation  at  this  time  (but  it  may  be 
able  to  do  so  after  a  short  while). 

E_CANT_CONSTRUCT 

The  update  to  be  transmitted  exceeds  a  local  size  limit. 

E  CANT  INCORPORATE 

The  update  received  exceeds  a  local  APDU  size  limit.  \ 

ECHAIN 

The  DSA  needs  to  use  chaining  to  carry  out  this  operation,  but  is  1 
prohibited  from  doing  so  by  Sen/ice  Controls.  | 

E_CREDENTIALS 

The  credentials  offered  do  not  match  those  of  the  object  with  which  1 
authentication  is  taking  place.  | 

E_DBE 

An  inconsistency  has  been  detected  in  the  DSA's  data  base,  which  may  1 
be  localized  to  a  particular  entry  or  set  of  entries. 

E_DIT_STRUCTURE 

An  attempt  was  made  via  an  add  operation  to  place  an  entry  in  the  DIB 
whose  object  class  would  violate  the  DIT  structure  rules. 

EDN 

A  DN  contains  an  RDN  wUh  two  AVAs  of  the  same  attribute  type. 

E_DSA 

A  DSA  to  which  chaining  is  taking  place  is  unable  to  respond. 

EENTRYEXISTS 

An  entry  of  the  given  name  already  exists,  causing  an  erro'. 

E_EXTENSION 

A  DSA  was  unable  to  satisfy  a  request  because  one  or  more  critical 
extensions  were  not  available. 

E  ILLEGAL  ROOT  OBJ 

_ 

Roofs  DN  has  been  supplied  as  the  object  of  a  Read,  Compare, 
AddEntry,  RemoveEntry,  ModifyEntry,  ModifyRDN,  or  as  the  Base 
Object  of  a  single  level  search. 

E_ILLEGAL_ROOT_VAL 

Roofs  DN  has  been  supplied  illegally  as  an  attribute  value  (e.g.,  as  an 
Aliased  Object  Name). 

E  INACTIVE  AGREEMENT 

The  specified  is  not  currently  active. 

E  INVAUD  AGREEMENT 

.  A  valid  agreement  does  not  exist  with  the  DSA. 

E_LOOP 

A  loop  has  been  detected  in  the  knowledge  information  within  the 
system. 

1  EMATCH 

The  attribute  specified  does  not  support  the  required  matching 
capability. 

EMISSEDPREVIOUS 

The  value  received  in  lastUpdate  or  is  not  consistent  with  the  time  the 
recipient  DSA  understands  was  the  time  of  the  last  update. 

E_MISSING_AVA 

When  creating,  or  after  modifying,  an  entry,  an  AVA  in  the  entry's  RDN 
is  not  represented  within  the  entry's  set  of  attributes. 

1  E_MISSING_OBJECT_CLASS 

When  creating  an  entry,  the  entry  does  not  possess  an  object  class. 

E_MORE_CURR_UPD_RCD 

A  consumer  DSA  processing  supplier-initiated  updates  determines  that 
the  update  the  supplier  is  attempting  to  send  is  older  than  one  the 
consumer  has  already  received. 

E  MULTI  DSA 

The  operation  is  an  update  operation  which  affects  other  DSAs. 

E_NAMING_VIOLATION 

The  name  of  the  new  or  modified  entry  is  incompatible  with  Its  object 
class. 

E  NO  AGMT  W  THIS  DSA 

The  receiving  DSA  has  no  agreements  in  place  with  the  sending  DSA. 
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Table  10  -  Error  symptoms  (continued) 


Symptom 

Description 

E_NON_LEAF_OPERATION 

The  operation  being  attempted  is  illegal  except 
on  a  leaf. 

E  NONMAMING  ATTRIBUTE 

In  Ait"hflr  an  at^d  or  ModifvHDN  oi3Prai"ion  an 
attribute  is  included  in  the  last  RDN  that  is 
not  a  valid  neuning  attribute  according  to  the 
DIT  structure  rules. 

E_NOT_SINGLE_VALUED 

An  attribute,  registered  as  single-valued,  has 
been  found  with  more  than  one  value. 

E  NO  SUCH  ATT 

The  specified  attribute  has  not  been  found. 

E  NO  SUCH  OBJECT 

The  specified  entry  has  not  been  found. 

found . 

E_OBJECT_CLASS_MOD 

An  (illegal)  attempt  has  been  made  to  alter  or 
remove  an  object  class  attribute. 

E_OBJECT_CLASS_VIOL 

There  is  a  schema  violation  (e.g.,  missing 
mandatory  attribute,  or  non-allowed  attribute 
present) . 

E_PREVIOUSLY_COORD 

A  supplier  DSA,  while  processing  consumer- 
initated  updates,  has  received  a 
coordinateShadowUpdate  referring  to  a  shadow 
agreement  for  which  a  previous 
coordinateShadowUpdate  has  already  been 

E_PREVIOUSLy_SOLICITED 

A  supplier  DSA,  while  processing  consiuner- 
initated  updates,  has  received  a 

agreement  for  which  a  previous 
requestShadowUpdate  has  already  been  received 
and  is  still  outstanding. 

E_REFERENCE 

An  erroneous  reference  has  been  detected  (e.g., 
DSA  cannot  handle  name  even  as  far  as  the 
number  of  RDNs  that  have  already  been 
resolved) . 

E_SCOPE 

No  referrals  were  available  within  the 
requested  scope. 

E_SYSTEM_PERM 

A  serious  and  permanent  software  or  system 
error  has  been  detected  which  prevents 
completion  of  the  operation. 

E_SYSTEM_TEMP 

A  serious  but  temporary  software  or  system 
error  has  been  detected  which  prevents 
completion  of  the  operation. 

E_TIMEOUT 

The  operation  has  not  completed  within  the 
allotted  time. 

E_T IMESTAMP_MI SMATCH 

An  unrecoverable  timesteunp  mismatch  has  been 
detected. 
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Table  10  -  Error  symptoms  (continued) 


Symptom 

Description 

E_UNABLE_TO_COMPLETE 

The  DSA  is  unable  to  comolete  this  oneratlon 
or  others  like  it  (this  applies  particularly  to 
search) . 

E_UNABIiE_TO_PROCEED 

The  DSA  czuuiot  satisfy  the  operation  after 
receiving  it  on  the  basis  of  a  valid 
non-specific  subordinate  reference. 

E_UNCOORDINATED 

A  consumer  DSA,  while  processing  supplier- 
initated  updates,  has  received  an  updateShadow 
request  for  which  there  is  no  outstanding 
coordinateShadowUpdate . 

E_TOO_MANy_UPDATES 

Supplier  DSA  determines  that  there  are  too  many 
updates  for  incremental  refresh  and  that  a  full 
update  is  required. 

E  UNDEFINED  ATT 

An  unregistered  attribute  has  been  encountered. 

E_UNRELIABLE_DATA 

A  DSA  has  detected  internal  data 
inconsistencies . 

E_UNSOLICITED 

A  consumer  DSA,  while  processing  consumer- 
initated  updates,  has  received  an  updaVeShadow 
for  which  there  is  no  outstanding 
requestShadowUpdate . 

E_UNSUPPORTED_CX: 

The  object  class  of  the  entry  is  not  supported 
as  a  valid  object  class  for  entries  within  this 
DSA. 

E_UNSUPPORTED_STRAT 

The  refresh  strategy  selected  is  not  supported 
by  this  DSA. 

E_UNUSABLE_DATA 

A  consumer  DSA  has  decided  that  the  received 
data  is  completely  unusable  due  to  error. 

E  VERSION 

An  unexpected  version  has  been  found  in  Bind. 

E_ZERO_VALUES 

An  attribute  has  been  found  (e.g.,  as  a  result 
of  a  modify-entry  operation)  with  no  values. 

1 
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Table  11  -  Error  situations 


Situation 

Description 

ABANDON 

An  Abandon  operation  is  being  carried  out. 

ADD-ENTRY 

The  entry  is  being  generated. 

ADD-ENTRY-NAME-RESOLUTION 

During  an  add  entry  operation,  name  resolution  has  been 
successfully  accomplished  on  the  superior  object,  and  is  not  being 
carried  out  to  determine  whether  the  new  entry  already  exists. 

BINO-LOCAL 

A  bind  IS  being  attempted;  either  the  entry  named  is  (or  should  be) 
within  a  local  naming  context,  or  name  resolution  is  being  carried 
out  on  the  part  of  the  name  that  is  known  locally. 

BIND-REMOTE 

A  bind  is  being  attempted,  and  the  entry  named  is  not  within  a  local 
naming  context;  remote  validation  of  credentials  is  being  carried 

out 

COMPARE 

A  Compare  operation  is  being  carried  out  on  the  entry. 

COORDINATE-SHADOW-UPDATE 

The  shadow  consumer  has  received  a  coordinateShadowUpdate 
from  the  supplier  DSA  and  is  evaluating  its  contents. 

UST 

A  List  operation  is  being  carried  out  on  the  entry. 

MODIFY-ENTRY 

The  entry  is  being  modified. 

MODIFY-RDN 

The  RDN  is  being  modified. 

NAME-RESOLUTION 

Name  resolution  is  being  carried  out. 

READ 

The  entry  is  being  read. 

REMOVE-ENTRY 

The  entry  is  being  removed. 

REQUEST-SHADOW-UPDATE 

The  supplier  DSA  is  processing  a  RequestShadowUpdate  received 
from  a  consumer. 

REQUEST-SHADOW-UPDATE- 
RESULT 

The  consumer  DSA  has  received  a  reply  to  a  request  for  update. 

SEARCH-ENTRY 

A  Search  operation  is  being  carried  out;  the  required  entry 
information  is  being  evaluated  or  acted  upon. 

SEARCH-FILTER 

A  Search  operation  is  being  carried  out;  the  filter  is  being  evaluated 
or  acted  upon. 

TRACE-EVALUATION 

The  trace  element  is  being  evaluated  for  loops. 

UPDATE-SHADOW 

The  consumer  DSA  has  received  an  UpdateShadow  from  the 
supplier  and  is  trying  to  incorporate  the  updated  information. 
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Table  12  -  Notation  used  to  describe  error  actions. 


Error  Action  Notation 

Meaning 

Rej 

A  reject  operation  is  generated,  with  problem  mistyped-argunnent. 

Ab(<qualrfier>) 

Abandon  Failed  Error  is  generated.  The  qualifier  may  take  on  values  codified 
as  follows: 

CA  •  Cannot  abandon  | 
NSO  -  No  such  operation 
TL  -  Too  late 

A(<  qualifier  >) 

Attribute  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 
follows: 

AVE  -  Attribute  or  value  already  exists  1 
CV  -  Constraint  violation  1 
IAS  -  Invalid  attribute  syntax  1 
IM  -  Inappropriate  matching 
NSA  -  No  such  attribute 
UAT  -  Undefined  attribute  type 

N(<qualifier>) 

NameError  is  generated.  The  qualifier  may  take  on  values  codified  as  follows: 
ADP  -  Alias  dereferencing  problem 

AP  •  Alias  problem  I 
IAS  -  Invalid  attribute  syntax  0 
NSO  •  No  such  object  1 

SH(<qualifier>) 

Shadow  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  11 
follows:  U 
lAID  -  Invalid  Agreement  ID  1 
lA  -  Inactive  Agreement 
MR  -  Invalid  information  received 

IS      -  Invalid  Sequencing 
US      -  Unsupported  strategy 

MP      -  Missed  previous 
FUR    -  Full  update  required 
UWP    -  Unwilling  to  perform 
UT     -  Unsuitable  timing 
UAR    -  Update  already  received 

SC(<qualifier>) 

Security  Error  is  generated.  The  qualifier  may  take 

on  values  codified  as  follows: 

lA    -    Inappropriate  authentication 
lAR  -  Insufficient  access  rights  1 
IC    -    Invalid  credentials  | 
IS    -    Invalid  signature  | 
NI    -    No  information  | 
PR    -    Protection  required  || 
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Table  12  •  Nottltion  used  to  describe  error  «ction«.  (concluded) 


Error  Action  Notation 

Meaning 

S(<qualifier>) 

Service  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 

follows: 

ALE  -  Administrative  limit  exceeded 

B  -  Busy 

CR  -  Chaining  required 

DE  -  Dit  Error 

IR  -  Invalid  reference 

LD  -  Loop  detected 

OOS  -  Out  of  Scope 

TLE  •  Time  limit  exceeded 

UA  •  Unavailable 

UAP  -  Unable  to  proceed 

UCE  •  Unavailable  critical  extension 

UWP  •  Unwilling  to  perform 

U(<  qualifier  >) 

Update  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 
toWows: 

AMD    •  Affects  multiple 

DSAEAE  -  Entry  already  exist 

NAN    •  Not  allowed  on  non-leaf 

NAR    •  Not  allowed  on  RDN 

NV     -  Naming  violation 

OCV    •  Object  class  violation 

OMP    -  Object  dass  modification  prohibited 
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Table  13  -  Error  actions 


Symptom 
(See  Table  10) 

Situation  (See  Table  11) 

Bind- 
Local 

Bind- 

Remote- 

Resolution 

Name- 
Resolution 

Add-Entry- 

Name- 

Resolution 

Add-Entry 

Modify- 
Entry 

E_ACCESS 

SC(IAR) 
(14) 

SC(IAR) 
(14) 

SC(IAR) 
(14) 

SC(IAR)(14) 

E  ADMIN  UMIT 

S(UA) 

S(UA) 

S(ALE) 

S(ALE) 

S(ALE) 

S(ALE) 

E  AUAS  DEREF 

S(IC) 

S(IC) 

N(ADP) 

E  ALIAS  LOOP 

E  AUAS  PROBLEM 

S(IC) 

S(IC) 

N(AP) 

EARGBOUNDS 

(8) 

(7) 

S(UWP) 
(12) 

S(UWP) 
(12) 

S(UWP) 
(12) 

S(UWP)(12) 

E  ARG  SYNTAX 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

E  ARG  VIOL 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

E  ATT  BOUNDS 

SC(IC) 

(7) 

N(IAS) 
(15,  16) 

N(IAS) 
(15,  16) 

A(CV) 

A(CV) 

E  ATT  OR  VALUE  EXISTS 

A(AVE) 

A(AVE) 

E_ATT_SYNTAX 

SC(IC) 

(7) 

N(IAS) 
(15,  16) 

N(IAo) 
(15,  16) 

A  /I  A  0\ 

A(IAo) 

A  /I  A  0\ 

A(IAb) 

EATTVALUE 

SC(IC) 

(7) 

N(IAS) 
(15.  16) 

N(IAS) 
(15,  16) 

A(IAS) 

A(IAS) 

E  AUTHENTICATION 

SC(IA) 

SC(IA) 

E  BUSY 

S(UA) 

S(UA) 

S(B) 

S(B) 

S(B) 

S(B) 

E  CANT  CONSTRUCT 

E  CANT  INCORPORATE 

E  CHAIN 

S(CR) 

E  CREDENTIALS 

SC(IC) 

SC(IC) 

E  DBE 

S(UA) 

S(UA) 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

E  DIT  STRUCTURE 

U(NV) 

E  DN 

SC(IC) 

SC(IC) 

N(NSO) 

C(NV) 

E  DSA 

S(UA) 

S(UA) 

S(UA) 
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Table  13  -  Error  actions  (continued) 


Symptom 

Situation  (See  Table  11) 

(o6«  laolO  iQ| 

Bind- 

1  ocal 

Bind- 
Remote- 

Name- 
Resolution 

Add-Entry- 
Name- 

Add-Fntrx/ 

Modify- 

Fntrv 

^1  nil  y 

E  ENTRY  EXISTS 

U(cAc} 

E  EXTENSION 

S(UWP) 

S(UCE) 

S(UCc) 

S(UCE) 

E  ILLEGAL  RCX)T  OBJ 

N(NdU; 

N(NoU) 

EJLLEGAL_ROOT_VAL 

(7) 

N(lAo) 
(15.  16) 

(15,  16) 

A/I  AC\ 

A/l  AO\ 

A(lA\o/ 

E  INACTIVE  AGREEMENT 

E  INVAUD  AGREEMENT 

E  LOOP 

S(UA) 

S(LD) 

E  MATCH 

SC(IC) 

SC(IC) 

A(IM) 

A(IM) 

A(IM) 

E  MISSED  PREVIOUS 

E  MISSING  AVA 

U(NAR) 

U(NAR) 

E  MISSING  OBJECT  CLASS 

U(OCV) 

U(OMP) 

E  MORE  CURR  UPD  RCD 

E  MULTI  DSA 

U(AMD) 

E  NAMING  VIOLATION 

U(NV) 

E  NO  AGMT  W  THIS  DSA 

E  NO  ENTRIES  IN  ST 

E  NON  LEAF  OPERATION 

E  NONNAMING  ATTRIBUTE 

U(NV) 

E  NOT  SINGLE  VALUED 

A(CV) 

A(CV) 

E  NO  SUCH  ATT 

A(NSA) 

E  NO  SUCH  OBJECT 

SC(IC) 

SC(IC) 

N(NSO) 

E  NO  SUCH  VALUE 

A(NSA) 

E  OBJECT  CLASS  MOD 

U(OMP) 

E  OBJECT  CLASS  VIOL 

U(OCV) 

U(OCV) 

E  OUTSIDE  UOR 
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Table  13  -  Error  actions  (continued) 


Symptom 
(See  Table  10) 

Situation  (See  Table  11) 

RinrL 

Dinu* 
Local 

Bind- 

nomoie- 

Resolution 

Name- 
nesoiunon 

Add-Entry- 
name- 
Resolution 

Add-Entry 

Moaiiy- 
Entry 

E  PREVIOUSLY  COORD 

E  REFERENCE 

S(UA) 

S(IR)  (17) 

E  SCOPE 

S(OOS) 

E  PREVIOUSLY  SOLICITED 

E  SYSTEM  PERM 

S(UA) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

E  SYSTEM  TEMP 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

E  TIMEOUT 

S(UA) 

(9) 

S(TLE) 

S(TLE) 

SfTLE) 

S(TLE) 

E  TIMESTAMP  MISMATCH 

E  TOO  MANY  UPDATES 

E  UNABLE  TO  COMPLETE 

E  UNABLE  TO  PROCEED 

(2) 

(2) 

E_UNCOORDINATED 

E  UNDEFINED  ATT 

SC(IC) 

(3) 

U(NV) 

A(UAT) 

A(UAT) 

E  UNREUABLE  DATA 

E  UNSOUCITED 

E  UNSUPPORTED  OC 

U(OCV) 

E  UNSUPPORTED  STRAT 

EUNUSABLEDATA 

E  VERSION 

S(UA) 

E_ZERO_VALUES 

A(CV) 

A(CV) 
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Table  13  ~  Error  actions  (continued) 


bymptom  (bee  isu3ie  lO) 

 — — — — ^— 

Situation  (See  Table  11) 

Modify-RDN 

Remove-Entry 

Read 

Compare 

Trace- 
Evalu- 
ation 

E  ACCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

EADMINUMIT 

S(ALE) 

S(ALE) 

S(ALE) 

E_ALIAS_DEREF 

E  ALIAS  LOOP 

E  AUAS  PROBLEM 

E  ARG  BOUNDS 

S(UWP)(12) 

S(UWP)(12) 

S(UWP)(12) 

EARGSYNTAX 

Rej 

Rej 

Rej 

Rej 

Rej 

EARGVIOL 

Rej 

Rej 

Rej 

Rej 

Rej 

E  ATT  BOUNDS 

N(IAS) 

A(CV) 

(7) 

EATTORVALUEEXISTS 

EATTSYNTAX 

N(IAS) 

A(IAS) 

(7) 

E  ATT  VALUE 

N(IAS) 

A(IAS) 

(7) 

EAUTHENTICATION 

E  BUSY 

S(B) 

S(B) 

S(B) 

S(B) 

E  CANT  CONSTRUCT 

E  CANT  INCORPORATE 

ECHAIN 

ECREDENTIALS 

EDBE 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

E  DIT  STRUCTURE 

EDN 

A(CV) 

A(IAS) 

EDSA 
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Table  13  -  Error  actions  (continued) 


Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Moany-nUN 

Remove-Entry 

neaa 

Compare 

Trace- 
Evaluation 

EENTRYEXISTS 

E  EXTENSION 

E  ILLEGAL  ROOT  OBJ 

N(NoU) 

N(NoU) 

N(NSO) 

E  ILLEGAL_ROOT_VAL 

A  /I  A  OV 

A(IAS) 

(7) 

E  INACTIVE  AGREEMENT 

E  INVAUD  AGREEMENT 

E_LOOP 

E  MATCH 

A/IM\ 

A(IM) 

(7) 

E  MISSED  PREVIOUS 

E  MISSING  AVA 

E  MISSING  OBJECT  CLASS 

E  MORE_CURR_UPD_RCD 

E  MULTI  DSA 

1  i/&iuin\ 

E  NAMING  VIOLATION 

\J\rt\/) 

E  NO  AGMT  W  THIS  DSA 

 — — — — 

E  NO  ENTRIES  IN  ST 

ENONLEAFOPERATION 

U(NAN) 

U(NAN) 

E  NONNAMING  ATTRIBUTE 

E  NOT  SINGLE  VALUED 

A(CV) 

E  NO  SUCH  ATT 

A(NSA)(4) 

A(NSA)(4) 

E  NO  SUCH  OBJECT 

E  NO  SUCH  VALUE 

E  OBJECT  CLASS  MOD 

E  OBJECT  CLASS  VIOL 

U(OCV) 

E  OUTSIDE  UOR 
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Table  13  -  Error  actions  (continued) 


1 
1 

1  Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Modifv-RDN 

R  fimovd-  E  ntrv 

s  iwi  0 1  w w^ki  111  y 

Read 

Trace- 
Fvaluation 

E  PREVIOUSLY  COORD 

E  REFERENCE 

E  SCOPE 

E  PREVIOUSLY  SOUCITED 

E  SYSTEM  PERM 

S^UWP^ 

S^LIWP\ 

E  SYSTEM  TEMP 

E  TIMEOUT 

SfTLE) 

SfTLE) 

SrTLE) 

E  TIMESTAMP  MISMATCH 

E  TOO  MANY  UPDATES 

E  UNABLE  TO  COMPLETE 

E  UNABLE  TO  PROCEED 

E  UNCOORDINATED 

E  UNDEFINED  ATT 

A(UAT) 

A(NSA)(4) 

A(NSA) 

(7) 

E  UNREUABLE  DATA 

E  UNSOUCITED 

E  UNSUPPORTED  OC 

E  UNSUPPORTED  STRAT 

E  UNUSABLE  DATA 

E  VERSION 

E_ZERO_VALUES 

(11) 
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Table  13  -  Error  actions  (continued) 


Symptom  (See  Table  10) 

Situation  (See  Table  1 1) 

List  (Filter) 

Search  (Filte^ 

Search  Entry 

AbarKlon 

E  ACCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

E  ADMIN  UMIT 

S(ALE)(13) 

S(ALE)(13) 

S(ALE)(13) 

E  ALIAS  DEREF 

(5) 

E  ALIAS  LOOP 

(5) 

E  ALIAS  PROBLEM 

(5) 

E  ARG  BOUNDS 

S(UWP)(12) 

S(UWP)(12) 

S(UWP)(12) 

E  ARG  SYNTAX 

Rej 

Rej 

Rej 

Rej 

E  ARG  VIOL 

Rej 

Rej 

Rej 

E  ATT  BOUNDS 

A(CV) 

E  ATT  OR  VALUE  EXISTS 

E  ATT  SYNTAX 

A(IAS) 

E  ATT  VALUE 

A(IAS) 

E  AUTHENTICATION 

E  BUSY 

S(B) 

S(B) 

S(B) 

E  CANT  CONSTRUCT 

E  CANT  INCORPORATE 

E  CHAIN 

E  CREDENTIALS 

E  DBE 

S(DE) 

S(DE) 

S(DE) 

E  DIT  STRUCTURE 

E  DN 

A(IAS) 

E_DSA 

(5) 
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Table  13  -  Error  actions  (continued) 


Symptom  (See  Table  10) 

Situation  (See  Table  11) 

List  (Filter) 

Search  (Filter) 

Search  Entry 

Abandon 

E  ENTRY  EXISTS 

E  EXTENSION 

S(UCE)(13) 

S(UCE)(13) 

S(UCE)(13) 

E  ILLEGAL  ROOT  OBJ 

(10) 

E  ILLEGAL  ROOT  VAL 

A(IAS) 

E  INACTIVE  AGREEMENT 

E  INVAUD  AGREEMENT 

E  LOOP 

(5) 

E  MATCH 

A(IM) 

E  MISSED  PREVIOUS 

E  MISSING  AVA 

E  MISSING  OBJECT  CLASS 

E  MORE  CURR  UPD  RCD 

E  MULTI  DSA 

E  NAMING  VIOLATION 

E  NO  AGMT  W  THIS  DSA 

E  NO  ENTRIES  IN  ST 

E  NON  LEAF  OPERATION 

E  NONNAMING  ATTRIBUTE 

E  NOT  SINGLE  VALUED 

E  NO  SUCH  ATT 

ENOSUCHOBJECT 

E  NO  SUCH  VALUE 

E  OBJECT  CLASS  MOD 

E  OBJECT  CLASS  VIOL 

EOUTSIDEUOR 

f 
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Table  13  -  Error  actions  (continued) 


1   

1  Symptom  (See  Table  10) 

Situation  (See  Table  11) 

List  (Filter) 

Search  (Filter) 

Search  Entry 

Abandon 

1  E_PREVIOUSLY_COORD 

3  E_REFERENCE 

E  SCOPE 

c  PRcVIOUSLY  oOUCITcD 

E  SYSTEM  PERM 

S(UWP) 

S(UWP) 

S(UWP) 

Ab(CA) 

C  oYoTcM  TEMP 

S(UA) 

S(UA) 

S(UA) 

Ab(CA) 

E  TIMEOUT 

SfrLE)(13) 

S(TLE)(13) 

S(TLE)(13) 

E_TIMESTAMP_MI5MATCn 

E_TOO_MANY_UPDATES 

E_UNABLE_TO_COMPLETE 

(B) 

S(B) 

S(B) 

Ab(CA) 

E  UNABLE  TO  PROCEED 

E_UNCOORDINATED 

E  UNDEFINED  ATT 

(6) 

(6) 

E  UNRELIABLE  DATA 

E  UNSOUCITED 

E  UNSUPPORTED  OC 

E  UNSUPPORTED  STRAT 

E  UNUSABLE  DATA 

E  VERSION 

E  ZERO  VALUES 
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Table  13  -  Error  actions  (continued) 


Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Coordinate 

onauow 

Update 

Update 

onauOW 

Request 
onauow 
Update 

E  ACCESS 

E  ADMIN  UMIT 

E  AUAS  DEREF 

E  AUAS  LOOP 

E_AUAS_PROBLEM 

E  ARG  BOUNDS 

E_ARG_SYNTAX 

E  ARG  VIOL 

 —  — 

E  ATT  BOUNDS 

E_ATT_OR_VALUE_EXISTS 

E  ATT  SYNTAX 

E  ATT  VALUE 

E  AUTHENTICATION 

E  BUSY 

SH,(UT) 

SH(UT) 

SH(UT) 

E  CANT  CONSTRUCT 

SH(UWP) 

E  CANT  INCORPORATE 

SH(UWP) 

E  CHAIN 

ECREDENTIALS 

E  DBE 

E  DIT  STRUCTURE 

E  DN 

EDSA 
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Table  13  -  Error  actions  (continued) 


Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Coordinate 
Shadow 

Update 
Shadow 

Request 
Shadow 
upoaie 

E  ENTRY  EXISTS 

E  EXTENSION 

E  ILLEGAL  ROOT  OBJ 

EJLLEGALROOTVAL 

EJNACTIVEAGREEMENT 

SHHA^ 

E  INVAUD  AGREEMENT 

Qi-in&in\ 

E  LOOP 

E  MATCH 

E  MISSED  PREVIOUS 

on^ivir  y 

E  MISSING  AVA 

E  MISSING  OBJECT  CLASS 

E  MORE  CURR  UPD  RCD 

E  MULTI  DSA 

E  NAMING  VIOLATION 

E  NO  AGMT  W  THIS  DSA 

SH(IAID) 

SH(IAID) 

SH(IAID) 

E  NO  ENTRIES  IN  ST 

SH(NI) 

E  NON  LEAF  OPERATION 

E  NONNAMING  ATTRIBUTE 

E  NOT  SINGLE  VALUED 

E  NO  SUCH  ATT 

SH(IIR) 

E  NO  SUCH  OBJECT 

SH(IIR) 

E  NO  SUCH  VALUE 

E  OBJECT  CLASS  MOD 

E  OBJECT  CLASS  VIOL 

EOUTSIDEUOR 

SH(IIR) 
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Table  13  -  Error  actions  (continued) 


=89  BEB 

Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Coordinate 
Shadow 

Update 

Update 
Shadow 

Request 
Shadow 
Update 

E  PREVIOUSLY  COORD 

SH(IS) 

E  REFERENCE 

E  SCOPE 

E  PREVIOUSLY  SOLICITED 

SH(IS) 

E  SYSTEM  PERM 

SH(UWP) 

SH(UWP) 

SH(UWP) 

E  SYSTEM  TEMP 

SH(UT) 

SH(UT) 

E  TIMEOUT 

ETIMESTAMPMISMATCH 

SH(FUR) 

SH(FUR) 

E_TOO_MANY_UPDATES 

SH(FUR) 

E_UNABLE_TO_COMPLETE 

E  UNABLE  TO  PROCEED 

E_UNCOORDINATED 

SH(IS) 

E  UNDEFINED  ATT 

E  UNREUABLE  DATA 

SH(FUR) 

E_UNSOUCITED 

SH(IS) 

E  UNSUPPORTED  OC 

E  UNSUPPORTED  STRAT 

SH(US) 

SH(US) 

E  UNUSABLE  DATA 

SH(IIR) 

E  VERSION 

E_ZERO_VALUES 
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Table  13  -  Notes  (continued) 


NOTES 

1  Use  A-U-ABORT.  Note,  however,  that  extra  elements  are  permitted  here. 

2  An  *unable-to-proceed'  error  becomes  SC(IC)  for  bind  and  N(NSO)  for  operations  if  no  DSA 
contacted  can  located  the  object. 

3  An  undefined  attributed  encountered  during  name  resolution  is  only  an  error-  N(NSO)  -  if  the  entry  is 
Identified  as  local.  See  also  Note  10  below. 

4  The  A(NSA)  condition  is  reserved  in  the  case  of  'read'  for  the  situation  when  no  attribute  of  the 
specific  list  provided  can  be  returned  (fOr  reasons  that  include  security  errors). 

5  Any  ^lure  to  propagate  a  search  causes  abandonment  of  that  part  of  the  search. 

6  Undefined  attributes  are  regarded  as  not  matched  or  found,  but  cause  no  errors  in  search. 


7  This  error,  if  detected,  should  be  ignored;  processing  continues. 


8  This  error  would  occur  as  a  result  of  a  bind  argument  with  a  name  containing  too  many  RDNs  for 
the  DSA.  Use  either  S(UA)  or  S(IC). 

9  DSAs  should  use  the  time-limit  service  control  with  local  timeout  to  limit  the  remote  validation  of 
credentials;  if  the  operation  fails  as  a  result,  S(UA)  is  used. 


10  For  a  single-entry  search,  N(NSO)  may  be  used. 


11  Either  the  v^ole  attribute  should  be  removed,  or  the  deleteOldRDNflag  should  be  ignored. 

12  Wherever  S(UWP)  appears  in  the  above  tables  beside  EARGBOUNDS,  a  ROSE  'Rej'  is  also 
admissible. 

13  The  error  is  returned  when  there  are  no  partial  results,  otherwise  a  partialOutcomeQualifier  with  the 
appropriate  limitProblem  is  returned  (cf  Directory  Documents,  Part  3,  item  g  of  clause  12.8.2,and  Part 
3.  clause  10.1.3.3.1). 

14  In  every  case  v^ere  a  security  error  occurs,  except  in  bind,  SC(NI)  may  he  used  in  place  of  the 
specified  problem,  to  support  a  Security  Policy  which  states  that  no  information  on  the  problem  may 
be  divulged.  In  the  case  of  the  bind,  SC(NI)  is  not  available. 

15  If  a  multicasting  DSA  receives  this  error  and  the  matched  part  of  the  name  is  equal  to  or  longer 
than  that  indicated  by  the  next  RDN  to  be  resolved,  name  resolution  shall  be  taken  as  having 
progressed.  The  error  shall  be  relayed. 

16  If  a  chaining  or  multicasting  DSA  receives  this  error  and  the  matched  part  of  the  name  is  not  equal 
to  or  longer  than  that  indicated  by  the  next  RDN  to  be  resolved,  the  error  indicates  an  incompatibility  in 
schema  between  the  DSA  and  the  one  to  which  chaining  takes  place.  Multicasting  may  continue,  and 
the  error  in  that  case  may  be  ignored.  A  DSA,  having  received  such  an  error  during  name  resoltuion, 
may  but  need  not  relay  it.  I 
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NOTES 

17  If  a  DSA  generates  a  chained  operation  on  the  basis  of  a  cross  reference  and  receives  a 
serviceError  with  the  probletn  of  invalidReference  in  response,  then  it  is  recommended  tlutt  tfie  invalid 

L cross  reference  t>e  removed  to  eliminate  repeated  errors.  Note  that  attempting  to  resolve  ttie  correct 
refererKe  via  the  retumCrossRefe  mechanism  should  be  regarded  as  nonreliable  due  to  tt\e  optional 
nature  of  retumCrossRefs.  The  resolution  of  an  invalidReference  due  to  a  superior  or  subordinate 
refererice  is  a  local  administrative  issue. 


Table  14  -  Simple  credential  fields  and  protected  simple  authentication 


Simple  Credential  Field 
name 
timel 
time2 
rarKiomI 
random2 
password 


Equivalent  Notation  in  Directory 
Documents,  Part  8,  figure  2 


t 


protected2 
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Annex  A  (normative)  

Maintenance  of  Attribute  Syntaxes 

A.1  Introduction 

The  attribute  types  defined  in  the  Directory  Documents,  Part  6,  and  listed  in  table  1  have  requirements,  In 
DSAs  which  support  them,  for  underlying  algorithms  that: 

a)  check  attribute  values  for  syntactical  correctness  and  compliance  with  pragmatic  constraints; 

b)  match  attribute  values  (comparing  for  equality,  for  matching  substrings,  and  for  relative 
ordering). 

A.2     General  Rules 

A  DSA  may  receive  a  legitimately  encoded  attribute  or  AVA  that  is  unsupported  by  the  DSA.  If  the  DSA  is 
not  required  to  act  on  it,  or  to  store  it  within  an  entry,  it  may  handle  it  by  passing  it  on  without  error.  Such 
attributes  may  also  l^e  used  in  search  filter-Item  definitions:  in  this  case,  no  error  is  reported,  but  the 
filter-item  shall  be  deemed  to  be  undefined  for  all  entries  in  the  DSA.  This  rule  applies  to  occurrences  of 
attributes  in  both  operation  arguments  and  results. 

Conversely,  a  DSA  must  retum  a  suitable  error  if  an  operation  requires  it  to  act  on  or  store  an  attribute  or 
AVA  of  type  unsupported  by  the  DSA.  This  constraint  applies  even  for  AVAs  that  are  contained  in  attributes 
that  take  names  as  values,  since  the  DSA  will  be  unable  correctly  to  match  the  attribute  values  without  this 
attribute  information. 


A.3     Checking  Algorithms 

The  subclauses  below  give  additional  checks  (b>eyond  those  directly  implied  by  the  Directory  Documents) 
which  shall  be  applied  to  attributes  before  they  are  stored  in  the  DSA. 

A.3.1  distinguishedNameSyntax 

Each  component  AVA  must  be  checked,  unregistered  attribute  types  comprising  an  error;  check  also  that 
no  two  AVAs  in  the  same  RDN  have  the  same  attribute  type. 

A.3.2  integerSyntax 

Local  implementations  may  apply  local  limitations. 
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A.3.3  telephoneNumberSyntax 

The  vcriue  of  policing  further  rules  is  for  further  study  (this  applies  also  to  telexNumber, 
teletexTerminalldentifier,  facsimileTeiephoneNumber,  GSFacsimileNonBasicParameters,  x1 21  Address,  and 
iSDNAddress). 

A.3.4  countryName 

The  value  must  be  checked  for  compliance  with  ISO  3166: 1981  (E/F).  (Note  that  from  time  to  time  further 
codes  may  be  allocated.) 

A.3.5  preferredDeliveryMethod 

The  values  of  the  integer  elements  should  not  be  restricted. 

A.3.6  presentatlonAddress 

No  further  checks  should  be  applied. 

A.4     Matching  Algorithms 

Matching  algorithms  are  conveniently  defined  in  terms  of  a  two-step  process: 

■ 

a)  Take  the  checked  reference  value,  and  the  value  to  be  matched,  and,  if  necessary,  reduce  them 
to  a  canonical  (i.e.,  standard)  form  (normalization)  appropriate  to  each  attribute  syntax. 

b)  Carry  out  the  comparison  in  the  specified  way  (e.g.,  equality,  substrings  or  ordering)  using  the 
appropriate  rules  for  the  value  -  character  string,  integer,  boolean,  etc. 

Note  that  the  lexical  ordering  of  character  strings  (when  supported)  may  be  subject  to  local  rules. 

IMPORTANT  NOTE:  The  combination  of  normalization  and  comparison  may  be  replaced.  In  a  particular 
implementation,  by  equivalent  procedures.  Additional  notes  on  normalization  are  given  below. 

A.4.1  UTCTImeSyntax 

if  the  "seconds'  field  is  absent,  it  shall  be  inserted,  and  set  to  "00",  and  the  form  converted  to  the  "Z"  ^ 
form.Note.  The  normalization  strategy  does  not  match  times  where  the  stored  form  omits  the  seconds  field, 
and  the  compared  form  contains  it,  e.g., 

8804261 91 9Z 

8804261 91 926Z 

(It  might  have  been  expected  that  these  two  forms, which  coincide  in  time  to  within  a  few  seconds,  would 
be  considered  identical.) 
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A.4.2  distlnguishedNameSyntax 

For  each  attribute  value,  carry  out  normalization  in  accordance  with  the  normalization  rules  defined  for  the 
type  (if  registered);  values  corresponding  to  unregistered  attribute  types  are  left  unchanged  at  this  stage. 

A.4.3  caselgnoreUstSyntax 

To  facilitate  matching,  particularly  for  substrings,  normalization  may  be  considered  in  terms  of  a 
representation  which  replaces  the  separate  ASN.1  elements  by  a  single  string  with  a  delimiter. 


85 


Part  11  -  Directory  Services  Protocols 


December  1992  (Stable) 


Annex  B  (informative)  

Glossary 

The  following  abbreviations  may  be  useful;  not  all  are  used  within  these  agreements. 


ACL  Access  Control  List 

ACSE  Association  Control  Service  Element 

ADDMD  Administration  Directory  Management  Domain 

AETItle  Application  Entity  Title 

APDU  Application  Protocol  Data  Unit 

ASE  Application  Service  Element 

ASN.1  Abstract  Syntax  Notation  - 1 

AVA  Attribute  Value  Assertion 

BRM  Basic  Reference  Model 

CA  Certification  Authority 

CCITT  The  International  Telegraph  and  Telephone  Consultative  Committee 

GEN  Committee  for  European  Nomnaiization 

CENELEC  Committee  for  European  Normalization  Eiectronique 

CEPT  Committee  of  European  Posts  and  Telephones 

COS  Corporation  for  Open  Systems 

DAP  Directory  Access  Protocol 

DIB  Directory  Information  Base 

DIT  Directory  Information  Tree 

DMD  Directory  Management  Domains 

DSA  Directory  System  Agent 

DSP  Directory  System  Protocol 

DUA  Directory  User  Agent 

EWOS  European  Worl<shop  for  Open  Systems 
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FTAM  File  Transfer,  Access  &  Management 

INTAP  Interoperability  Technical  Association  for  Information  Processing,  Japan 

ISDN  Integrated  Services  Digital  Network 

ISO/IEC  International  Organization  for  Standardization 

KT  Knowledge  Tree 

U.  Lower  layers  of  OSI  model  (layers  1-4) 

MAP  Manutecturing  Automation  Protocol 

MHS  Message  Handling  Systems 

NIST  National  Institute  of  Standards  and  Teciinoiogy 

NSAP  Network  Services  Access  Point 

OSI  Open  Systems  Interconnection 

PKCS  Public  Key  Crypto  System 

POSI  Promotion  for  Open  System  interconnection 

PRDMD  Private  Directory  Management  Domain 

PSAP  Presentatton  Service  Access  Point 

RDN  Relative  Distinguished  Name 

ROSE  Remote  Operatkxis  Servtee  Element 

SSAP  Session  Service  Access  Point 

SIG  Special  Interest  Group 

SPAG  Standards  Promotion  &  Application  Group 

TOP  Technical  and  Office  Protocols 

TSAP  Transport  Seo^ce  Access  Point 

UL  Upper  layers  of  OSi  model  (layers  5-7) 

UPU  Universal  Postal  Union 
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Annex  C  (informative)   

Requirements  for  Distributed  Operations 

The  following  material  is  included  for  tutorial  purposes,  and  does  not  represent  material  additional  to  the 
Directory  Documents.  It  is  also  not  intended  as  a  complete  statement  of  requirements  (the  Distributed 
Operations  part  of  the  Directory  Documents  should  be  referred  to  for  a  complete  treatment). 

C.1      General  Requirements 

DSAs  supporting  distributed  operations  and  claiming  support  of  chaining  must  fully  support  DSP,  as  defined 
by  the  Directory  Documents.  DSAs  supporting  distributed  operations  must  always  be  able  to  accept 
incoming  DSP  associations  and  Invocations.  DSAs  claiming  support  of  chaining  must  support: 

a)  Loop  detection 

b)  Loop  avoidance 

In  passing  on  operations  (when  chaining  or  multi-casting),  the  original  DAP-supplied  invocation  must  be 
passed  on  without  change  of  content,  in  particular,  there  must  be  no  alteration  in  anyway  of  any  primitive 
content. 

The  support  of  a  facility  for  returning  cross-references  (Directory  Documents,  Part  4,  clause  10.4.1)  is 
optional. 

To  ensure  that  tracelnformation  can  be  analyzed  properly,  DSAs  shall  only  possess  names  that  are 
compliant  with  the  recommendations  of  the  Directory  Documents,  Part  7  (including  Annex  B). 

C.2     Protocol  Support 

C.2.1       Usage  of  ChainingArguments 

When  using  ChainingArguments:^ 

a)  originator  need  not  be  used  if  requestor  in  CommonArguments  is  used; 

b)  targetObject  shall  not  be  used  unless  the  target  object  differs  from  object/base  object  (if  it  is 
present,  object/base  object  are  ignored  for  purposes  of  name  resolution); 

c)  operationProgress,  tracelnformation,  aliasDereferenced,  aliasedRDNs,  referenceType,  and 
timeLimit  shall  be  generated,  accepted,  and  used  in  accordance  with  the  Directory  Documents; 

d)  returnCrossReferences  and  info  may  optionally  be  generated,  and  shall  always  be  accepted. 


^In  this  subclause,   the  names  of  protocol  elements  (within 
ChainingArguments)  are  italicized. 
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C.2J2      Usage  of  ChainingResults 

When  using  ChainingResults:^  crossReferences  and  info  may  optionally  be  generated,  and  shall  always  be 
accepted. 


^In  this  subclause,   the  names  of  protocol  elements  (within 
ChainingResults)  are  italicized. 
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Annex  D  (informative) 

Guidelines  for  Applications  Using  the  Directory 
D.1  Tutorial 


D.1.1  Overview 

Applications  may  have  a  requirement  for  Directory  functionality.  This  tutorial  provides  assistance  to  those 
groups  intending  to  specify  Directory  usage  for  a  specific  application  (e.g.,  Message  Handling  Systems). 

D.I  .2       Use  of  the  Directory  Schiema 

D.I  .2.1        Use  of  Existing  Object  Classes 

Applications  wishing  to  use  the  Directory  should  have  determined  within  a  standard,  Implementor's 
Agreements,  or  on  a  propriety  basis,  the  relevant  Directory  schema  for  their  objects.  Consider  the  following 
two  examples: 

a)  Network  management  applications  may  with  to  define  a  SMAE  object  class; 

b)  File  transfer  applications  may  with  to  define  a  File  Store  object  class. 

Groups  should  examine  relevant  standards  to  determine  if  application-  specific  object  classes  or  attributes 
have  been  already  defined  before  considering  any  additional  definition.  These  object  classes  and  attributes 
may  be  found  In  a  variety  of  places  Including  a  specific  application  standard  (e.g.,  [Recommendation  CCITT 
'88  X.402  I  ISO  10021-2]  and  the  Directory  Documents.).  Standardized  object  classes  and  attributes  should 
be  strongly  considered  before  additional  schema  elements  are  created. 

D.I. 2.2        Kinds  of  Object  Classes 

There  are  effectively  two  kinds  of  object  classes  permitted  within  the  Directory  Documents:  structural  and 
auxiliary.  The  terms  structural  and  auxiliary  are  used  here  for  convenience  when  referring  to  particular  kinds 
of  object  classes.  The  terms  themselves  are  not  defined  in  the  Directory  Documents. 

Structural  object  classes  have  associated  DIT  structure  rules  (which  control  naming).  Entries  of  this  object 
class  type  are  intended  to  be  instantiated  In  Directory  entries.  A  structural  object  class  provides  information 
on  the  base  mandatory  and  optional  content  of  a  DIT  entry. 

An  auxiliary  object  class  provides  information  to  enhance  the  mandatory  and  optional  contents  of  entries. 
It  Is  always  used  in  conjunction  with  a  structural  object  class. 

The  object  class  hierarchy  Is  formed  as  a  result  of  the  definition  of  structural  object  classes,  and  the  addition 
of  auxiliary  object  classes. 

For  example,  all  object  classes  In  the  Directory  Documents,  Part  7,  are  structural  except  for  strong 
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Authentication  User  and  certification  Authority.  These  two  object  dassas  should  be  considered  auxiliary  and 
used  In  conjunction  with  other,  structural  object  classes. 

D.I  .2.3       Use  of  Unregistered  Object  Classes 

The  Directory  Documents,  Part  2,  dause  9.4.1  provides  a  "special"  fomn  of  object  class  called  "unregistered." 
An  unregistered  object  dass  is  not  assigned  an  object  identifier.  One  of  the  uses  for  unregistered  object 
dasses  is  to  provide  a  means  of  creating  a  single  Directory  entry  which  logically  represents  a  variety  of 
object  dasses.Uses  for  unregistered  object  dasses  indude: 

a)  Locally  adding  attributes  to  a  predefined  superdass; 

b)  Locally  mai<ing  optional  attribute  types  in  a  predefined  superclass  mandatory; 

c)  Creating  an  object  class  derived  from  multiple  superclasses,  without  needless  proliferation  of 
registered  object  classes. 

For  example.  It  may  be  advantageous  to  provide  an  entry  which  represents  a  person  wfio  is  both  a  MIHS 
and  a  FTAM  user. 

Unregistered  object  classes  may  best  be  illustrated  by  example.  Consider  an  entry  which  represents  a 
collection  of  company  entries  for  Fizzy  Company  whose  users  have  MIHS  0/R  addresses.  Using  the 
guidelines  above,  the  Fizzy  Company  defines  an  unregistered  object  dass  using  the  structural  object  dass 
or^nizationalPerson  from  the  Directory  Documents,  Part  7,  and  the  auxiliary  object  class  mhs-user  from 
the  MHS  standards  [Recommendation  X.402  j  ISO  10021-2]  as  follows: 

£  i  z  zyCompeuiyPe  r  son  : :  =  OBJECT-CLASS 

SUBCLT^S  OF  organizationalPerson,  mhs-user 
MUST  CONTAIN  {} 
MAY  CONTAIN  {) 

Note  that  no  object  identifier  is  assigned. 

Also  note  that  since  there  are  not  MUST  or  MAY  CONTAIN's  in  the  fizzyCompanyPerson  Object  Class,  the 
last  two  lines  of  the  object  dass  assignment  (i.e.,  "MUST  CONTAIN  MAY  CONTAIN")  are  optional.  As  with 
the  registered  form  of  object  dasses,  an  unregistered  object  class  always  inherits  all  the  attributes  in  any 
of  its  superdasses.  There  is  no  mechanism  defined  whereby  a  subclass  may  selectively  inherit  attributes 
from  Its  superclasses. 

An  unregistered  object  dass  always  appears  as  a  leaf  in  the  Object  Class  tree.  (i.e..  An  unregistered  object 
dass  may  not  be  a  superclass  of  some  other  object  class). 

Using  unregistered  object  classes  in  conjunction  with  multiple  inheritance  is  useful  as  shown  by  figure  4 
in  which  three  ways  of  creating  the  same  two  object  classes  are  shown.  Either  three,  four,  or  five  registered 
object  dasses  are  used. 

Examples  (a)  and  (c)  in  figure  4  are  both  better  ways  of  defining  the  object  classes  than  that  In  example 
(b),  even  though  example  (c)  needs  to  use  one  more  registered  object  class  than  example(b).  This  is 
because  the  multiple  inheritance  technique,  used  in  examples  (a)  and  (c).  enables  a  Directory  User 
searching  the  Directory  to  easily  create  a  filter  to  find  all  entries  that  contain  mhs-user  attributes,  based  on 
a  value  in  the  object  class  attribute  (Each  Directory  entry  contains  a  list  of  the  object  identifiers  of  the  object 
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classes  tt  has  Inherited  from,  so  the  "filter  would  Just  have  to  find  all  entries  that  held  the  object  identifier 
value  of  mhs-user). 


per 
\ 

mhs 

sshs  ae 

/     \  / 
-per[ur]  i&hs-ae[ur] 

per  ae 

1  1 
1  1 

mhs-per  mhs-ae 

per  mhs 

\       /  \ 
mhs-per  mhs 

ae 

/ 
-ae 

Example  a 

Example  b 

Example  c 

[ur] 
per 
nhs 
ae 

=  unregistered 

~  person 

=  mhs-user 

=  applicationEntity 

Figure  4  -  Three  ways  of  creating  two  object  classes 


Example  (a),  which  uses  three  registered  object  classes,  is  better  than  example  (c),  which  uses  five,  because 
registering  the  extra  two  object  classes  does  not  provide  any  advantage  over  not  registering  them,  and  the 
first  method  avoids  needless  proliferation  of  registered  object  classes. 

D.I  .2.4       Side  Effects  of  Creating  Unregistered  Object  Classes 

This  subclause  discusses  two  side  effects  of  creating  unregistered  object  classes. 

a)  When  an  unregistered  object  class  is  defined  from  a  single  superclass,  there  is  no  means 
available  to  distinguish  between  the  two.  Within  the  local  scope  for  which  the  unregistered  class  is 
defined,  all  relevant  entries  are  considered  to  belong  to  the  unregistered  class. 

The  following  is  an  example  of  this  problem: 

An  object  class  of  oCI  (reg)  has  attribute  type  at1  mandatory  and  at2  optional.  An  unregistered  form 
of  this,  oCl  (unreg)is  created,  which  makes  at2  mandatory.  When  an  Add  Entry  operation  is  received 
with  both  attributes  present,  the  entry  could  belong  to  either  form  of  oCI ;  it  is  indeterminate.  After 
the  entry  is  added  a  Modify  Entry  operation  is  received  which  requests  the  removal  of  attribute  type 
at2.  It  is  not  clear  if  this  operation  should  succeed,  or  whether  an  object  class  violation  should  be 
reported.  If  the  attribute  may  be  removed,  then  the  entry  belonged  to  the  oCl  (reg)  object  class  and 
the  unregistered  form  never  existed,  othen/vise  if  the  attribute  may  not  be  removed,  then  the  entry 
belonged  to  oCl  (unreg)  and  the  registered  form  no  longer  exists. 

b)  More  than  one  unregistered  object  class  cannot  be  defined  from  the  same  superclass(es)  for 
use  within  the  same  local  scope,  as  there  is  no  means  available  to  distinguish  the  classes  from  one 
another. 
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D.2     Creation  of  New  Object  Classes 

If  no  appropriate  object  class  Is  available,  a  new  object  class  may  be  defined.  This  should  only  be  done  if 
no  standardized  object  classes  and  attributes  can  fulfill  the  requirements. 

D.2.1       Creation  of  New  Subciasses 

Generally,  an  application-specific  object  class  is  defined  as  a  subclass  of  a  pre-existing  Directory  object 
dass.  These  object  classes  are  specified  in  the  Directory  Documents,  Part  7.  The  subclass  may  k>e  structural 
or  auxiliary.  Optional  attributes  of  the  superclass  may  be  made  mandatory.  New  attributes  may  also  be 
added. 

For  example,  MHS  has  used  the  Directory  structural  object  class  applicationEntity  to  derive  the  object  dass 
for  their  MHS-specific  application  entity  MTAs. 

If  absolutely  no  relevant  object  class  is  available,  an  object  class  may  be  defined  as  a  subclass  of  the  basic 
object  dass  called  Top." 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This  should  only  be 
undertaken  if  no  standardized  object  class  can  fulfill  the  requirements.  When  defining  new  object  classes 
the  object-class  macro,  as  defined  in  the  Directory  Documents,  Part  2,  clause  9.4.6,  should  be  used. 

If  new  subclasses  are  defined,  suggested  or  required  name  forms  may  also  be  specified  in  text. 
D.2.2      Creation  of  New  Attributes 

If  no  appropriate  attributes  are  available,  a  new  attribute  type  may  be  defined.  This  should  only  be 
undertaken  if  no  standardized  attributes  can  fulfill  the  requirements.  When  defining  new  attributes  the 
attribute  macro,  as  defined  in  the  Directory  Documents,  Part  2,  clause  9.5.3,  should  be  used. 

D.3     DIT  Structure  Rules 

Applications  may  desire  to  provide  guidance  on  DIT  structure  rules  and  naming.  As  with  object  classes, 
standardized  or  suggested  structure  (including  naming)  rules  from  the  Directory  Documents  part  7,  Annex 
B  and  application-specific  standards  should  be  consulted  before  providing  new  structure  rules.  Annex  B  in 
the  Directory  Documents,  Part  7,  provides  guidelines  on  how  to  specify  this  information.  Structure  rules 
associated  with  superclasses  should  be  adopted  wherever  suitable. 

D.4      Use  of  AETITLE 

Applications  wishing  to  make  use  of  the  AETitle  field  to  access  applicationEntity  objects  in  the  Directory  are 
refen-ed  to  Amendment  1  to  ISO8650  for  guidance  on  the  purpose  and  appropriate  useage  of  the  AETitle 
field.  In  particular,  implementors  should  be  aware  that: 

a)  AETitle  should  be  used  to  uniquely  distinguish  individual  application  entities.  It  is  inappropriate 
for  applications  to  define  a  fixed  AETitle  to  apply  to  all  its  instantiations; 
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b)  The  Directory  does  not  perform  name  resolution  on  an  object  identifier  (e.g.,  AETItle  name  form 
2).  The  Directory  does  support  lookup  based  on  OID.  and  AETitle  name  form  2  does  not 
constitute  a  Directory  Distinguislied  Name. 
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Annex  E  (informative)  

Template  for  an  Application  Specific  Profile  for  Use  of  the  Directory 

The  template  defined  below  should  be  used  by  OIW  SIGs  Intending  to  specify  Directory  usage.  Such 
application  specific  profiles  shall  be  contained  In  application  specific  chapters  of  the  OIW  agreements.  The 
Infonnatlon  under  each  heading  should  be  filled  In  (the  text  under  each  heading  provides  guidance  on  the 
meaning  of  the  heading  and  should  not  be  included  in  the  profile). 

a)  PROFILE  TITLE 

Application  specific  profiles  are  named  in  the  following  way: 

OIW  <SIG-NAME>  <DESCRIPTOR>  DIRECTORY  PROFILE 

(e.g..  OIW  DIRECTORY  STRONG  AUTHENTICATION  DIRECTORY  PROFILE  ) 

!  b)  OTHER  PROFILES  SUPPORTED 

Other  OIW  Directory  profiles  which  are  to  be  used  by  this  specific  application  are  listed  here. 
'  Attributes,  attribute  sets,  object  classes  and  structure  rules  that  are  referenced  in  these  profiles  need 

not  be  enumerated  below. 

c)  STANDARD  APPUCATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

Any  attributes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG  might  include 
mhs-or-address  here. 

I  d)  STANDARD  APPLICATION  SPECIFIC  OBJECT  CLASSES 

Any  object  classes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG  might  include 
mhs-user  here. 

e)  OIW  APPUCATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application  specific 
j  attributes  and  attribute  sets.  This  section  of  this  template  should  be  used  rarely  and  with 

consideration  that  no  standard  profile  or  attribute/attribute  set  exists  which  can  be  used. 

f)  OIW  APPLICATION  SPECIFIC  OBJECT  CLASSES 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application  specific 
object  classes.  This  section  of  this  template  should  be  used  rarely  and  with  consideration  that  no 
standard  profile  or  object  class  exists  which  can  be  used. 

1  g)  STRUCTURE  RULES 

Guidance  for  DIT  structural  rules,  provided  only  when  stnjcture  mies  associated  with  superclasses 
are  not  adopted.  The  Directory  Documents,  Part  7,  Annex  B  provide  an  example  and  guideline  to 
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use  in  specifying  this  Infonnation. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Security  Special  Interest 
Group  (SECSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW)  hosted  by  the 
National  Institute  of  Standards  and  Technology  (NIST).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part 
replaces  the  previously  existing  chapter  on  this  subject.  There  is  significant  technical  change  from  this 
text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as 
change  pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will 
be  shown  as  shaded. 
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Part  12  -  Security 

EdKor's  Note  -  Previous  material  in  this  part  has  been  deleted  and  is  no  longer  applicable. 


0  introduction 

The  relationship  between  protocols  and  security  is  accomplished  by  developing  a  security  profile  that 
binds  these  two  together.  Security  profiles  define  protocol  specific  implementations  of  security 
architectures. 

I    A  security  profile  includes  the  following  items: 

j  a)  A  grouping  of  the  security  services  to  be  offered; 

b)  The  placement  of  those  security  services; 

c)  The  selection  of  mechanisms  to  support  the  placed  security  services. 

This  part  completes  this  sequence  of  steps  for  several  generalized  security  architectures.  A  generalized 
security  architecture  is  chosen  and  tailored  to  derive  a  protocol-specific  security  profile.  This  part  is 
comprised  of  protocol-specific  security  profiles  and  other  supporting  functions. 


1  Scope 


2     Normative  References 

[IS07498-2]     ISO/IEC  7498-2  Information  Processing  Systems  -  Open  Systems  interconnection  - 
Basic  Reference  l\/lodei  -  Part  2:  Security  Architecture,  February  1989. 

[IS08649]       ISO/IEC  8649:  1 988/Amd  1 : 1 990  Service  Definition  for  the  Association  Control  Service 
Element,  Amendment  1:  Peer-Entity  Authentication  During  Association  Establishment. 

[iSO8650]       ISO/IEC  9594-3  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  3:  Abstract  Service  Definition. 

I  [IS08650/1]     ISO/IEC  8650:  1 988/Amd  1:1990  Protocol  Specification  for  the  Association  Control 

Service  Element,  Amendment  1 :  Peer-Entity  Authentication  During  Association  Establishment. 

[IS09594-7]     ISO/IEC  9594-7  Information  Processing  Systems  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  7:  Selected  Object  Classes,  1990. 

[IS09594-8]     ISO/IEC  9594-8  Information  Processing  Systems  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  8:  Authentication  Framework,  1990. 

II  [IS010021-4]  ISO/IEC  10021-4  Information  Processing  Systems  -  Text  Communication  -  MOTIS  - 
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Message  Transfer  System  :  Abstract  Service  Definition  and  Procedures. 
[X.509-88]      CCITT  X.509:1 988  The  Directory  -  Authentication  Framework. 
[X.511-88]      CCITT  X.51 1 :1 988  The  Directory  -  Abstract  Service  Definition. 
[X.41 1  -84]      CCITT  X.41 1 : 1 984  Message  Transfer  System  -  Message  Transfer  Layer. 
[X.521-88]      CCITT  X.521 :1 988  The  Directory  -  Selected  Object  Classes. 

3  Definitions 

4  Symbols  and  Abbreviations 


5  Architectures 

OSi  appScatlim  envlrommint  and  Its  threats  ami  vuNierablKtleSx 


A  Security  Architecture 

specifies  the  relatkmshlplsetween  the  set  of  secnolty  sen^s  m&  r^echanlsms 

with  iMtUi!^ 

protection 

Irorft  ^V8$t$^ 

and  vginerabiHties 

i$  achieved*  H  h  «fe$i0fta<*  to  r^sppfid 

assessed 

vtitnerabilitles. 

,  threatSr  and 

risks  as  identified 

by  a  secudty  policy.  The  estabishmertt 

of 

$ecuNty  policies  i$  i?eyontl  the  $ccpe 

0f  the  oiw. 

5.1  Introduction 

OpeiQ  Systems  Seouf lly  isrovldes  for  secure  cistributed  Motrmiaon.  processing  %n  OSI  appllca^on 
o^tviroofAi^t^  yMt^  a^e  heterodeneo^i^  iTi  ti^iS  dteic^wdiody  and  adnrHtiisira^ori*  Iht  example^  sonie 
env^ronm^ts  mav"  require  protectior>  if<m  a  minknai  set  of  security  threats  while  others  fe^uife  more 


The  aeouence  of 

steps  bv  which 

a 

securltv  arCshltecttire 

is 

:\i\t  dDoiication 

environm&it  is 

as 

follows 

rK 
* 

Dev^pment  of  threat  analysis; 

b)  Determtnatton  of  security  services; 

c)  Hacement  of  security  services; 
A)  Selection  of  oiet^nlsms; 

«|  Selector!  of  alsiorithms. 
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appgc«^<»>»      IntfiKtitctis^  10  the  ^fiafWalya^  process  and  the  datermmatton  of  S6<aarltv  «»:yjcM 

by  ISO  74^8-2  are  ^rotped  ^«to  classes  in  Clause  6»3»  A  generalized  security  afchitecture  for  each 
aflvkeififti^  i$  M'^k^^  by  la^l^pHtg  th^  s^cvrity  or>t6  the  functionaJ  firoup$  of  each 

tnviroRmwt  ao^  iw&vlcSrjg  gulclaHce  aa  to  at  which  layer  to  support  the  sen/ice  m  Clause  5,4. 
0«i<la«<sa  0«  h<^wt0  $^$Ct  mechar»l$ms  auitaW^f^r  presented  in  Clause  5,5. 

b^yoiid  the  $<50ji*  of  th^se  impl0meiit«i?m  ^j^^^itierita  to  apecih^  ws^  'of ^^;:aljSoH<h%^il 
ati^iff^  pause  7  preseots  »  set  of  adgiorithms  sijltable  for  various  mecharwsms^ 


5.2      Application  Environments 

tt  la  aseful  f«r  the  «M  <?f  simpBf^jjatw*  to  loolc  at  the  OSt  appiicatkm  environments  and  to  separate 
them  %mi  8^fjc  OSI  appli&atk»t  ^^^fonrneots  so  that  security  profiles  can  be  developed  for  eadi. 
The  envirorwTWPfta  are:  ^ngle.  App^ation  Association,  Application  Relay,  and  Distributed 
ApjplicatiortSx  AM  applcaiior^  \fM  t^rate  in  ooe  or  more  of  these  environnnems.  For  example,  a 
Mleasac^  Handiinsapplica^on  ti^atMses  ali^easaae  Trar^sf^  Agent  {MTA)  to  relay  maij  from  one  User 
Ajperit  iMJ^  to  another  UA  would  ^  the  AppScation  Relay  Environment,  bkewise  a  Message 
Hmi&inQ  application  which  only  Msjdea  a  UA  accessing  a  Message  Store  (MS^  would  ma^  to  the 
Sln#a  Appication  Assoetia^on  ^yirornnant 

l^or#ach  ^tmttmtmnt,  arohito<JttHtil  diagram  id  i^ovided  thatpCHtraya  th^lntercorsiecttoit 
of  «l0ntems.  in  a^lditSon^  a  ^et  of  funotior^  groups  are  <Jefifted  o^h  of  which  is 
ttompf Ised  of  atn  Int^rdtmn^ciecl  set  of  olementa* 


Base  Environment 


Figura  f  <^p'k^  the  baaic  < 

Miamant$  of 

a  jgenanc  OSl 

application  envlfonmertt  from  which  all  OSt 

apph'catlor^  environments  can  be  derived 

r  tn  all  applcation  environment  figiwes,  dashed  tines  indicate 

an  optional  conrniunication  path 

and 

t$te  doutd^Qned  boxes  indicate  an  optional 

basic 

element. 

ISNpses  Indicate  that  the  previous 

basics 

aiemertt  niay  be  repeated  zero  or  more  times, 

su 


mm 


Sft>  «*  Service  Agent 
§5  w  Service  System 
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The  basffii  eleniienis  ere  ae  fc^tows^: 

ServtE^  U$dr  |SU3^:  j»i  fmic^oQ^  as  e  se^rvice  initiator  m  fBspofv^ ; 

Service  Agent  ISA):;  m  jnteimedtat^^  entity  ti^si  actively  participates  in  provldlriQ  the  servicea 
feetweei*  m  loltiatof  and  a  responderi 

ServlDe  System  |S$^t  a^ero  or  more  icexi^retki^  ser^ce  aijeri^x 


11 

<£rect 

or 

}(itefmedlarie«r  ^«  t^aaslfled  aa 

a  f unctionai  group,  FunctionsI  groupa  defined 

in 

iigi(ire  1  are; 

a*  f^:  W->      {Serwce  User  to  Service  User  directly}; 
b,  l^rSU  '»>  SU  {Service  User  to  Serwce  User  indirectly]!;; 
e»  la:  SU  *>  SA  {Service  User  to  Service  Agent  directly  J; 
d.  l»rSU  »>  SA  ^Service  Us©- to  Service  Agent  Indirectly}; 
e*  l^i  SA     SA  ilSwvice  Agent  to  Service  Agent  <Jirec^y); 
f .  I»:  SA  (Service  Agent  to  Swvtce  Agent  indtrectlly)j 

fftt  SA  ->  SU  {Service  Agent  to  Service  User  directly}; 
b,  |,;SA»>$U  iService  Agent  to  Service  User  Indirectly}* 


Editor's  ^Mfi  * 

>* 

notation  indicates  association  secunty  r eiationsiilp  and  ''^> 

*  tndicafes  r^y 

security  relaticmsi^x 

Tbesa  de^nl^ons  this  fictional  ^roup  syntsx  will  be  iised  to  define  gerieric  OSI  ai^lca^ 
e»v{ro»m«»it9«  In  some  appllcationa,  these  functional  groups  may  have  to  be  combined  f0t  the  pmptm 
of  peif  orinlng  a  security  analysis. 


S.2.2      S^gle  Application  Association  Environment 

The  i^$e  AppiicatlCH^  Associate  Snvffonnientcover$  eppScations  which  sra  deslcm^d  to  opot^#^«l 
Single  Applicatkart  Assoclatl(ms  ias  denned  In  ^SO  9545^  between  one  pair  oi 
eppii^tiOn'^entitH^vocai^Ons  ^ACls^.  This  envffonment  spectficaily  tnqliANiS  the  Case  Of  recovery^  l-S^ 
ififferent  associatkms  may  exist  at  different  times  between  one  pair  of  AEIs. 
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*l|«|![%ll«eiur«l  fiSa^r^  forSlnj^e  Appllo&tloii  Ac»ocl8lI(m  SmilraMrtiflft 


iisiciidnsi  Oroups 

Ibiev^  ItiticiRmaP  groiip  1$  (tefined  for  tiie  Singra  AppSca^  A$d<x:M)n  infyfr^oi^tMm^ 
If  ^SU'*> 


|M>pt^ca1ioii  Belay  Environment 


i$0v«f$  lipisMii^h^  wl-|^|r#  %^^^p$r^e  ''iM  ITi^'icM 

'$^'Mm.  ooe  46rv^  agent    support  of  l^i^yrrlng  a  service  user  request  from  an 
'""Mf'^Wm  fliorethdrt  o^e  service  ^O^|^^^iyyi<?«o<i  $«<i««<*tt8By* 


<^  «io  ^ippBcation  to  which  this  environment 
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$>42;.3»t       Af<MQ0tMr9l  Diagram 


figura  ^  portrays  tb«  architecturat  diagram  for  the  Application  R«tay 

Sn^ronmem.  Un  tM  appiicailon 

(lla$liad  Ittias  ifH^cate:  m  optional  comrmmtcation  path 

indicate  an  optiotlal  iMisic  alem^it  Ikliipses  indicate  that  the  previous 

basic 

element  may  ba  repaated 

^rp  or  more 

1  SA   "1  i  \jSl&^  \ 

^   f 

Rgure  $  Archltecturat  dia 

Sir  m  Servi.<?«i  Onar 
SS  »  3ervioe  9)r9t:em 

sram  for  Application  Relay  Environment 

-       f  uncfloiial  <lroups 
Tha  foSowbg  functionat  groups  are  defined  and  added  for  tha  Application  Relay  Snvtronmant: 
1^:  SU  ->  SA; 
h  Ui  $U  *>  $A? 
fe,  f^:  SA  *>  SA; 

d*  ui  SA  sa 


S^*2*4      l)f»^lbut«<l  Appilca^o^  l^vlronmeni 


The  Dl&trtbuted  ^i^icatlon  Environment  covers  applications  which  are  designed  to  oft^ratB 

with  the 

active  participation  of  zero  or  mora  service  agents 

which  may 

process 

a 

service  user 

request. 

Procasa'mg  may  Include 

modifying,  interprei^ng^  or 

transferring  the 

service 

user  request 

or 

Its  data< 

Whef>  more  iJian  one  a^lca  agent 

is  present,  they 

may  function  in  parallet 

.  seQuentlaliy^ 

or 

both. 

B,2A,t       Arcftitectural  cSagram 


i%ira 

4  portrays  tha  arcttitecturiai  diagram  for  tha  Distributed  Appiica^ons 

Environment  In  ai 

application  anviromnent  figures,  dashed  6nes  Indicate  an  optional  communication 

pa^  andthe(k»ul^»' 
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Figure        chitectursi  diagram  for  Distributed  AppHcatbtUli  j&i^roili^aAl 


MmZA^Z       Pimc^omA  Croups 

The  following  functional  group*  ara<leflT«cl  and  added  for  the  O^atrlbutett  Applicatkma  Snvktwmwn? 
«^     SU  ->  {SU;  }; 
bI.f*;  .$U      {SU;  }; 
d  fg;  SU  ->  {$A; ...  |; 
0)  fftSSU      {SA;  >; 
e^  f*!  SA  ->  {SA;  ...  }; 
t|  V  $A    >  (SA'r ...  >; 


$A 

li 

{SU; 
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$9!C<itfHy  <;tas86s  ^re  defied  to  |>K>vt09  a  ffdmBwatk  m  whUih  to  tonMid  sdi^uNiy  i^rolM^s.  £9cH  €}as$ 
»pe<N^9  tf>e  required  «eGur%  services^  The^  services  specified  R>  «9id>  c^$»  jsnre  ^  irei^i^  seei.^ 

lor  eaeh  f^assi*  For  exanipie,  data  Im^tty  1$  »  fiienerK  security  «efvbo  lor  wNdi  ttiere  f»liti^  M 
diS'll^^iaEtaiiafidsiHtysdrvje^i^  O»»oritti^a  ^c^Jo  $ocuf% ^ervi^'mMst be  9p«oHlfid to m«6t the 
r»(Mre<Twmd  of  ^  secorlt^r  clasd  In  an  ^liea^on  specif^  saconiy  urofSe* 

Tbe  (Masses  are  orgfonlz^  Into  two  simiiar  bleirsB^hiies  as  sbovm  in  Tai^  !>.  SacN  levi^/i»f  ^each 
Neraroby  is  «  $vpefm  of  the  ^tnaiiy  $ervice$  re^uM  of  the  ii¥»n«id^ely  i)reca($»d  i^vei  f  or^etioN 
level  In  Hie  hlerard^es,  the  same  sat  of  sacofl^ty  serN^cas  are  required^  exGi^t^l  one,Mi»^y 
tnciyde*  oort«d^aiity  si^ica*. 

l8bleii:iii::!*;:;S^OUI^t$^:i:C9jS$SI^ 


SBcoRiTy  SEsvicass 

i     WOP  |>ATiV  IH7 

ADD  com 

SOA 

ADD  NOK^RB^U&IATiOl 

-i 

^  S2 

S2A 

Tb«9  are  two  loterastm^  properties  of  ^se  relationships  betwe^  tlia  i^assaSx  '  Rrst/^df  leMai 

the  oofif  ktentiaifty 

ht^rchy 

is 

a  superset  of  the  other  hierarchy  at  the 

tev< 

tihe  coofidentleNty 

hierarchy 

at 

the  immediately  precedioQ  level.  For  example. 

clas 

isS^I&esopers^ 

ot  ola^e«    «rKiE  St  A* 


Second^  for  two  entities  each  suppor^ns  a  distinct  security  cJess  In  a  cBffereht  hierarchy^  the  beat  Ceval 

of  scHTvIca  ^at  oar^  be  achieved  betvtreeo  '^em  Is  the  cl 

nonHeonlidi^allty  yarar<J«y^  at  i^ 
if  ^ne  entity  eupports  dasa  l^^t  and 

*:;SS.;:S|t:i: 

^e  oi^er  supports  class  S1  A,  the 

best  dass  of  service 

Editor's  Note  «  This  is  not  a  mechanism  for  negotiated  services.  That  is  a  future  work  Item. 
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ttie  $ecu^  Cladft  $0  in<;i«<le$  Irrti^ememaM    the  fo^w|cm  ^^qK^^M^I 

TPie^Seistiir^  O^ss      9ckt$  the  confidertti^tty  service  to  i^m  €^«|BPI1H 
bl  $0A    SO  ^  OxMwiM^* 

'Security  0a8s  SI 
The  $^       the       N^srity  $^l0i»  t9  <;td$$  SO  e»  li^^^ 

fl  ^^l     $0  ^  Data  Integrity* 
The  Security  Oess  $t  A  adds  the  Confideotlality  Service  to  Class  SI  ae  foBowe; 

bl  $1A    $1  ^  CQ()^Men^$l% 

'  SscurNy  Clas^  S2 

The  09tsi&  S2  add»  i^  NoD-repudiation  Service  to  Class  SI  as  foBow^; 

a|  $2     $t  ^  Mon^repudiailoii 
Tb#  $$eQr%        $2A  eM  th0  Cortlid^ttatity  $erN»oe  to  Class  $2  as  foSovv^t 

5.4      Guidelines  for  OIW  Application  Profile  Development 
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6     Key  Management 

[1S07498-2]  defines  Key  Management  (KM)  as  the  "generation,  storage,  distribution,  deletion, 
archiving,  and  application  of  keys  in  accordance  with  a  security  policy."  The  Security  SIG  recognizes 
that  security  policies  are  outside  the  scope  of  lAs,  and  it  is  inappropriate  to  make  general 
recommendations  in  the  absence  of  a  KM  framework. 


7     Security  Algorithms 

EdKor's  Note  -  Implementors  are  cautioned  that  security  of  an  algorithm  may  change  at  any  time. 
Therefore,  the  WIA  must  be  consulted  in  order  to  determine  if  there  is  more  current  information. 


The  algorithms  included  here  are  listed  in  no  particular  order  (beyond  (saitBQatmktlim  by  type  ol 
algoit^intl.  It  is  beyond  the  scope  of  these  agreements  to  recommend  the  use  of  one  algorithm  over 
another.  However,  if  a  vulnerability  is  known  to  exist  a  reference  will  be  provided  along  with  a 
recommendation  not  to  use  the  algorithm. 

This  clause  references  a  definitive  specification  for  each  algorithm,  which  includes  an  object  identifier. 
In  general,  control  of  the  definitive  specification  is  expected  to  be  outside  the  scope  of  the  OIW.  The 
benefit  of  not  controlling  the  specification  is  that  the  organization  that  developed  the  algorithm  is  best 
situated  to  maintain  and  have  knowledge  of  the  security  of  the  algorithm.  Algorithms  for  which  there 
is  no  controlling  organization  are  defined  in  an  Annex  in  this  Part. 

For  each  algorithm,  its  typical  usage  is  stated,  its  definitive  reference  is  given,  and  its  object  identifier 
is  included  for  reference  purposes. Optionally,  additional  information  may  be  included,  for  example  a 
reference  to  known  vulnerabilities. 

Iflr^en^otiiir^  i^MiAJid  ^yfit^m  that  export  ol  i^oducts  m^rh  trypto^aphy  m&y  i^ect  a^tpc^ 
fm^l&Som*  In  fpnenilr  vst^  of  crypt<^aphy  mt  InvoMng  confiden^^diti^  «s  soblect  CQmmwm 
Oi^rtmdQi  r^sMations,  y^Md  usd  of  ^s^ryptofg^phy  for  eimfiddntlaity  h  acaiteoM  by  ktncsrit  sitiin^imi4 
$tat»  Oep9nnnent  regutstioiis.  It  l»  the  inrtn^ementor's  respons9»Sty  tc^  ^jtetermlne  any  epqpon 
m$tii^c:^r{$  iMdfk  ^i(^y  to  a  ^ven  pfodmtt  as  tl^  export  eomtrols  may  chan^  trcm  tim»  to  i^m$. 

Editor's  Note  -  Some  of  the  references  are  RFCs,  Internet  Drafts,  and  PKCS  documents.  We  need  to 
include  information  on  how  to  access  these  documents. 
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7r1  Squore  Mod  N 

Squoro  Mod-N  io  o  hash  algorithm  that  ic  ucod  to  oomputo  o  fixod  oizo  roprosontation  of  on  input 
otroami  It  is  dofinod  in  [X.BOSl  and  ito  objoot  idontifior  ie  dofinod  thoro  aoi 

BqMod  n  ALCOniTim 
PARAMBTBR  BloekSiac 
If  (haohAlgorithin  Ir^ 

BlookSizo  INTEGER 

Rooont  roooaroh  regarding  tho  oquaro  mod  n  ono  way  haoh  function  doooribod  in  Annex  D  of  tX.6091 
hoa  revealed  that  the  function  io  not  oeeure.  Ito  use,  therefore,  io  dioeouroged. 


Editor's  Note — Wo  nood  tho  rof  oronoo  that  idontif  ios  its  vutnorobilitioo  oo  wo  oan  rooommond  it  not  be 


7.2      Message  Digests 

These  message  digest  algorithms  (or  hash  algorithms)  compute  a  fixed  size  representation  of  an  input 
stream.  They  have  different  performance  characteristics  and  employ  different  computational 
techniques,  making  each  suitable  for  different  applications. 


7*2*1  S<|u»re-IMo<l4«l 

m9(m,  it  1$  itefined  in  tX^SO0l  and  its  object  identifier  i$  defined  tbem  ^kt 
t*m  {hasbAIgorithm  1> 

llws^t  r«wwrc*i  regercfins  tfm  $qoare-?i«Kt-n  one*wdy  feesti  iimctm  ^^^iHi^^p.  CKJOff 
f^i^V^v^aled  that  the  fbnctk>ft  t&  mt  $«etim*  its  use,  th^fore^  b  at$(^^^^A 


fditoi^s  Ham « We      th^  re^^^s  that  id^mifieft  it$  yuir^er^ilrties    we  can  t<^fi<Httmend:itii^b| 
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MD2  is  a  message  digest  algorithm  that  employs  accepted,  traditional  computational  techniques.  Its 
speed  is  the  slowest  of  the  message  digests  listed  here. 

It  is  defined  in  Internet  Draft  [a]  and  its  object  identifier  is  defined  there  as: 

ind2  ALGORITHM 
PARAMETER  NULL 

it'  {i80(l)  member-body (2)  US (840)  rsad8i( 113549)  digestAlgorithm(2)  2} 

Editor's  Note  -  There  is  a  Directory  SIG  OID  for  this  algorithm. 

The  reference  includes  a  source  code  implementation  of  the  algorithm  written  in  the  C  programming 
language.  MD2  is  copyrighted  and  its  use  may  require  specific  permission  or  a  license.  Details  are 
stated  in  the  Internet  Draft. 


7.2.3  MD4 

MD4  is  a  message  digest  algorithm  that  employs  non-traditional  computational  techniques  to  enhance 
its  speed  in  software  and  hardware  with  native  32-bit  arithmetic.  Its  speed  is  the  fastest  of  the 
message  digests  listed  here. 

It  is  defined  in  Internet  Draft  [b]  and  its  object  identifier  is  there  as: 

md4  ALGORITHM 

PARAMETER  NULL 

{iso(l)  member-body(2)  US(840)  rsadsid  13549)  digestAlgorithm(2)  4} 


This  reference  includes  a  source  code  implementation  of  the  algorithm  written  in  the  C  programming 
language. 

It  is  suggested  that  MD4  be  used  only  with  applications  for  which  performance  is  critical. 

Editor's  Note  -  We  need  to  include  text  from  the  MD4/5  Internet  Drafts  which  describes  the  differences 
between  the  two  algorithms  and  the  preference  for  MD5. 


7.2.4 


MD5 


MD5  is  a  message  digest  algorithm  that  employs  traditional  oomputational  toohniquoo  with  the  opood 
onhanoomonto  of  MD<1  wbldi  U  bsseil  ofi  the  techr}kiue&  of  MD4,  but  wftfi  «<fdStlE»«^  »(^ncem«il» 

A  d^'M  ^ie$«fjptiori  0f  the  chaoge$  can  be 


t^liEp  is  defined  in  Internet  Draft  [c]  and  its  object  identifier  is  defined  there  as: 
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md5  ALGORITHM 
PARAMETER  NULL 

::=  {iso(1)  member-body (2)  US(840)  rsaclsl(1 13549)  cllgestAlgorlthm(2)  5} 


This  reference  Inciudes  a  source  code  implementatior)  of  the  algorithm  written  in  the  C  programming  language. 


fiZ3    ,  SH^ 

Pl^ilgi^j^li^ilifi  Ni$T  Secure  1^911  Algot!^  ll|«^lMMon«onoepte similar  to  those  used  fn  liP 
iid       and  ou^Ms  a  lltO^bit  digest 

Et^or'ft  ^le  *  This  «mi  odw  aigor^N^  may  be  ye^l^^md    ISO  imtead.  In  ii^Hk^  cetae  ihls  t«<t  itiriK 
adjusted  pricMrtQ  moMng  ro^ta^e  Agreemerast  orif  mc^stsaa^as  ^nmem  Etr^ 


7.3     RSAReversibie  Fybllc  K^y  Algorithms 

ItiodeiilSIQrllitm  areit^mmetric;  separale  )t^^nw^\mm«f^^w^^^f^^  TNey  ei$o  have  the 
pri^3fi% th^  ^^}iEy&ng  the  ar^lphaindnt  fUncttort  loiowed  |>y^iiie  dediplher^^i^iOi^     the  same  effedt 

algorMun  Is  needed  to  provide  both  CDnSdoBtlalil^  (a9<r»^sB'<spoR^  i^inmeiric  keys^  and 
e^jthertice^h/inte^ity  (e^g,*  dlg^t  ^ii^jimii^^ 


RSA  is  a  public  key  (asymmetric)  cryptographic  algorithm,  typically  used  in  conjunction  with  message  digest 
(or  hash)  algorithms  to  create  digital  signatures  and  for  confidential  distribution  of  symmetric  keys.  It  nr^y  also 
be  used  to  exchange  confidential  messages. 

The  RSA  algorithm  is  defined  In  [d]  and  is  also  described  In  Annex  C  of  [X.509].  The  RSA  technology  is 
patented  in  the  United  States  [e][f]. 


^p^p^lo  pc,809i,  the  A$N<t  BIT  STraNCS  cor«akilriif^pMM||^^WS^^^^ 
I  t»!3dulis»andestponent: 


7.4 


POA 


Cditor'e  Note  -  Explain  why  thoro  aro  two  dofinitionci 
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e 

IKITEGER, 
Xtil!EOSR 

—  wsas^ua 

7.4.1        RSA  Dofinition(X.509) 

RSA  is  defined  in  [X.509]  and  its  object  identifier  is  defined  tiiere  as: 


rsa  ALGORITHM 

PARAMETER  KeySize 

::=  {encryptionAlgorithm  1} 

KeySize  ::=  INTEGER 
Tlie  l<ey  size  specifies  ttie  length)  in  bits  of  the  RSA  public  key  modulus. 

Th»d^ik}n  oll^is  algortthm  does  not  include  specification  of  padding  nJes.  If  onto  assyme&thtalthe  data 
iStr^ed  as««^  llJteger  and  padded  with  zero  bits  on  the  left,  ttie  algorithm  is  $u&|^tO  va»tOltfta»acic$, 

those  desciibed  In  [ah]^  which  render  it  unsuitable  for  some  appllcatioris,  &g.t  imil&red^xient  ve>s&, 
80tafl2StJon.  Ift  such  case^  RSAEncryptlon  is  preferred;  s 

7.4.2       RSA  Encryption 


RSA  Encryption  is  defined  in  PKCS  #1  [g]  and  its  object  identifier  is  defined  there  as: 

rsaEncryption  ALGORITHM 
PARAMETER  NULL 

::=  {iso(l)  member-body ( 2 )  US(840)  rsadsi ( 113549 )  pkcs(l)  pkcs-l(l)  1} 

This  fllgofftlTm  defines  various  types  di  tirfock  padding  depending  on  whether  the  block  is  \s^s^  encrypted 
y$i»0  a  publlo  or}>rKf$t0  k$y.  The  padding  protects  again^  various  attacks  docurRonted  in  th$  IH^rature. 


1^5     Irreversible  Public  Key  Algorithms 

These  aigorfthffns  are  rral  reversS^e,  as  defined  In  section  7v2.  Typically,  drferent  atgori^ms  ara  used  for 
eitcryj^on  and  sigr^ture.  This  section  defines  several  signature-ortf y  algorithms.  Note  thj^i^hSSigsiSiligtcwitfJfftS 
sxpaynd  the  piainlext,  producing  output  whk;h  Is  signifk^antly  larger  than  the  input  block  or  dJgestgsi^hsse 
algorHhjTis  ar^  of  use  in  autherrtication-only  systems,  and  are  generally  not  subject  to  export  restricttws. 
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EIGamal  is  a  public  key  (asymmetric)  digital  signature  algorithm.  It  is  defined  in  (kl.  Its  object  identifier 
is: 

EIGamal  ALGORITHM 

PARAMETER  NULL 

::=  {encrypt ionAlgorithm  1} 

Editor's  Note  -  This  OID  was  assigned  by  the  Directory  SI6. 

In  [X.509],  the  ASN.1  data  element  subjectPublicKey  defined  as  BIT  STRING  should  be  interpreted  in 
the  case  of  EIGamal  as  being  of  type: 

SEQUENCE  { 

prime  INTEGER,   —  p 

base  INTEGER,     —  alpha 

key  INTEGER  —  public  key,  Y 

} 

Also,  in  [X.509],  the  value  associated  with  the  ENCRYPTED  MACRO  should  be  interpreted  in  the  case 
of  EIGamal  as  being  of  type: 

SEQUENCE  { 
a  INTEGER, 
r  INTEGER 
> 

The  EIGamal  technology  is  patented  in  the  United  States  [f]. 

Editor's  Note  -  Should  we  describe  and  define  OlDs  for  the  message  digest  with  EIGamal  signature 
algorithms?  There  is  a  Directory  SIG  OID  for  md2WithEIGamal. 


?,e     Key  Exchange 


Tt»  oi]|ect  Identifier  l»  ^eflneil  In  B^C^  p  Cp 
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ledtxf  deflator*  wtilchamc 

r.  1h$  patent 
Tf»  object;  idenfifier  Is  <feniied 


i 

P 

T.7  StgnatureAlgc^lfhrns 

Tiil$  H  number  of  $i^tijre  iy90f  ithm$.      ha$h  ^^^tm  <^blri$d  with  appfopi1at$ 


7:8  Square-Mod-N  with  R8A 

Square  Mcxi  N  io  a  olgnaturo  algorithm  that  oombinoo  tho  Square  Mod  N  haoh  algorithm  with  tho  RSA 
oryptographle  algorithm  to  produce  a  digital  oignature.  Thio  algorithm  lo  defined  In  [X.6001  and  Ito  objoot 
idontlfior  io  defined  there  ao: 

oqmod  nWithnSA  ALGORITHM 
PARAMETER  KoyAndBlookSigc 
n«  (signaturoAlgorithm  1} 

KoyAndBlookSiBO  ii-  INTEGER 

Reeont  reooareh  regarding  the  oquare  mod  n  one  way  haoh  funetlon  deoeribed  in  Annex  D  of  [X.600]  hao 
revealed  that  the  function  lo  not  oeoure.  Ito  uce.  therefore,  io  dioeouraged. 
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7.9      Measoge  Digests  with  RSA 


The  algorithms  listed  below  are  signature  algorithms  that  combine  a  message  digest  algorithm  with  the 
RSA  cryptographic  algorithm  to  produce  a  digital  signature. 

Editor's  Note  -  The  OlOs  below  have  been  assigned  by  the  Directory  SI6  and  the  Security  SIG.  Should 
we  explain  why  they  do  not  appear  in  a  single  tree? 


7.9.2       MD2  with  RSA 


mi 


Its  object  identifier  is: 

md2WithR8a  ALGORITHM 
PARAMETER  NULL 

{signatureAlgorlthm  1> 

EdKor's  Note  -  This  OID  was  assigned  by  the  Directory  SIG. 


7.9.3       i^D4  with  RSA 
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Its  object  identifier  is: 

md4WithRSA  ALGORITHM 
PARAMETER  NULL 
:5=  {algorittun  2} 

7.9.4       MD5  with  RSA 

Its  object  identifier  is: 

mdSWithRSA  ALGORITHM 
PARAMETER  NULL 

{algorithm  3} 

7.10    Message  Digests  with  RSA  Enoryptlon 

7.10.1  Message  Digests  with  SieryptlOd 

The  algorithms  listed  below  are  signature  algorithms  that  combine  a  message  digest  algorithm  with  the 
RSA  Encryption  cryptographic  algorithm  to  produce  a  digital  signature. 

7.10.2  MD2  with  RSA  Encryption 
T^^tOXl     ftfloa  WitliBSAfirteryption 

MD2  with  RSA  encryption  is  defined  in  PKCS  #1  [g]  and  its  object  identifier  is  defined  there  as: 

md2WithRSAEncryption  ALGORITHM 
PARAMETER  NULL 

::=  {iso(l)  member-body ( 2 )  US(840)  rsadsi( 113549)  pkc8(l)  pkC8-l(l)  2} 


I 
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Its  object  identifier  is: 


mdAWlthRSAEncryptlon  ALGORITHM 
PARAMETER  NULL 

{algorithm  4} 


7.10.4     MDB  with  RSA  Enoryption 


MD5  with  RSA  Encryption  is  defined  in  PKCS  #1  [g]  and  its  object  identifier  is  di^fined  there  as: 

mdSWithRSAEncryption  ALGORITHM 
PARAMETER  NULL 

{i80(l)  member-body (2)  US (840)  r8adBi( 113549)  pkc8(l)  pkc8-l(l)  4} 

— Pifffio  Holimon  Koy  Exchonge 

Diffio  Hollmon  Key  Eicohongo  io  o  public  key  (ooynr>metrio)  algorithm  whereby  two  portioo<  without  any 
prior  arrangements;  can  agree  upon  a  eoorot  koyi  Thie  koy  could  bo  uood;  for  ewamploi  to  onorypt 
furthor  oommunioationo  botwoon  the  partiooi 

The  Diffio  Hollman  Koy  Exchange  ia  defined  in  [hi  and  io  aloo  doooribod  in  [j].  The  Diffio  Hollmon  Koy 
EMchongo  io  patented  in  the  United  Statoo  liHf). 

The  object  identifier  ie  defined  in  PKCS  #3  (jl  ao! 

dhkeyaggeement  ALGORITHM 
PARAMETER  DHPagamotog 

II-  (ioo(l)  mQwbog-body(a)  U6(840)  goadoi(lia649)  phoo(l)  phoB-3(3)  1) 

DHPagameteog  i i -  6EQUBN0E  { 
pgimo  INTEGER y  --  p 
baoo  INTEGER  s 
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7t« — EI-Goma» 

EIGamal  io  a  public  koy  (aoymmotrio)  digital  signaturo  algorithmi  It  is  dofinod  in  [kli  Its  objoot  idontifior 

ElCaroal  ALCOniTHM 
PAnAMBTEn  NULL 

— (onoryptionAlgorithm  1) 

Editor's  Note  -  Thie  OID  wac  assignod  by  tho  Pirootory  8IGi 

In  [X.6081j  tho  ASM  J  data  olomont  oubjootPublioKoy  dofinod  oc  BIT  STRING  ohould  bo  intorprotod  in 
tho  0060  of  EIGamal  ao  boing  of  typo: 

OEQUENOE  ( 

pgimo  INTEGER I  p 

baoo  INTEGER; — ~ — alpha 

koy  INTEGER  public  koy/  Y 

■J- 

Also;  in  [Xi6081;  tho  valuo  asoooiatod  with  tho  ENCRYPTED  MACRO  should  bo  intorpreted  in  the  oase 
of  EIGan^al  ao  boing  of  typoi 

SEQUENCE  ( 
O  INTEGER/ 
g  INTEGER 
■J- 

Tho  EIGamal  toohnology  io  patontod  in  tho  United  Statoo  [fl. 

Editor's  Note — Should  wo  doooribo  and  dofino  OlDo  for  tho  moecago  digoct  with  EIGorrioi  cignaturo 
algorithms?  Thoro  is  a  Dirootory  SIG  OID  for  md2WithEIGamali 


7. 1 3    Doto  Encryption  StondordSymmetrre  gilier#ftoil  Ar^Olftfum 


7.13  J    Oata  incryp^n  Standard 

The  Data  Encryption  Standard  (DES)  is  a  secret  key  (symmetric)  cryptographic  algorithm.  It  is  defined 
in  FIRS  46-1  [I].  It  is  also  defined  as  DEA-1  in  ANSI  X3.92-1981  [m]. 

Implementors  will  also  find  several  other  references  useful.  FIRS  RUB  74  [p]  provides  guidance  on  the 
implementation  and  use  of  DES  and  includes  a  complete  specification  of  the  algorithm.  SREC  RUB 
500-20  [p]  describes  the  design  and  operation  of  the  NIST  (formerly  NBS)  testbed  that  is  used  for  the 
validation  of  DES  implementations.  It  specifies  a  set  of  291  test  cases  that  have  been  designed  to 
exercise  every  basic  element  of  the  algorithm,  and  as  a  further  check  on  the  correctness  of  an 
implementation,  it  specifies  an  extensive  Monte  Carlo  analysis.  SREC  RUB  500-61  describes  the  design 
of  four  maintenance  tests  for  DES  implementations.  The  tests  consist  of  an  iterative  test  procedure 
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that  uses  a  small  program  and  minimum  data.  The  tests  are  designed  to  be  independent  of 
implementation  and  to  be  fast  enough  to  test  devices  during  actual  operation.  The  tests  are 
defined  as  four  specific  stopping  points  in  a  general  testing  process  and  satisfy  four  testing 
requirements  of  increasing  degree  of  completeness  on  the  thoroughness  of  testing  desired. 
There  are  four  modes  of  operation  of  the  DES.  as  specified  by  FIPS  81  [n]  and  ANSI  X3. 106-1 983  [o]  The 
modes  specify  how  the  data  will  be  encrypted  and  decrypted.  In  ^1  cases  the  key  Is  64  bfts.  Usi^g  I 
*5fioa^  discussed  below  exoept  DES4ytAC)  m  si^ect  to  export  controls. 


7.13.1.1  DES-ECB 

This  Is  the  Electronic  Codebook  mode  of  operation.  Its  object  kJentifier  is: 

desECB  ALGORITHM 
PARAMETER  CDCParamctoriiiii 
::=  {algorithm  6} 

mode  ^wiM  be  useef  to  enctypt  sjm8  blocks  {e,5.»  olher  DES  l<eys).  Its  wae  is  <tepf^cdtea  for  Wock 
l^^^l^iOB  ^0C^|t  .^O«si  <;{$pl^ysls  of  fepeaiad  block  values  the  same  plalme)d;  In  the  same  place 
^li^tdlN^  i^iC^,        as  reasserf^lh0  rnesse^  lirom  khown  blocks. 


7.13.1.2  DES-CBC 

This  Is  the  Cipher  Block  Chaining  mode  of  operation.  Its  object  kJentifier  is: 

desCBC  ALGORITHM 
PARAMETER  CBCPareuneter 
(algorithm  7} 

The  PARAMETER  is  needed  to  specify  the  Initialization  Vector,  which  need  not  be  kept  secret. 

Tl^  mode  #K9uld  be  used  to  encrypt  multiple  biod<8«  where  the  full  message  is  avaii^e.  The  random  iV 
preventSiOOct$bookim3lv$^olthestd{t<^tb^       The  IVmay  be  public. 

TNsftKKl9>4ilpropd$^teasl»0iel^  error  It)  one  plal«te^  block  Irtto  ail  $uc(^$d^blocl^4^  willii^pa^e 

Slebiterrotrmthe 


WPi^Spgj|j^|i0 mechetfU^lPCit  fi^  j^ioulcf  be  used  »the  data  to  be  ertcfypted  Is  octelaf igned,  unless 


-  _  J  ,  ^  ^.-^.-...x,  .  >n the folfowtng  manner; 

p^S&Teiicpth  ^  octets'StS'Spi  ~^^  m  Inpt^tjJlpfSSI^i^Vmod  8)  octet  to  the  end  of  the 
feli^jp»«adithavlt*gthevalue8*{nmod%thenurtJberd^octetsbelng  added,  tn  hexadecimal,  the  possible 
|ii*^"^#t^'^8IV  0292,  G30m  04Q40404,  95Q5060505,  060606060606.  07070707070707,  and 
0806081)80808080^.  ^1  giput  Is  padded  with  1  to  8  octets 
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Wf^>f$im  ^         of  $  o^ei$  b  length.  Ihi^  ^$Kldlng  <m    rmcmd  mm^c^oimi^  sStm 

W^M'n  Note  « If  dddkiglhd  pdddfng  luie&woaid  CiauQd  «»M0  Irnpiomamdipni  Id  }N9  bd 
fftQistomd  as  «  $«p8f8i»  aigoritim  ldemH)«r.  Note.  licM«y»r«  thai      B1]  $p«0ili6»l(s  <m»  paddlr^^^  fear 

hsscai^       could  t»  conveyed  «s  »n  i^<»iit^  l=*ABAM£Hlt)  (^whe^rth«  dma  has  boen  pssfid^  oonct 


7.13.1.3  DES-OFB 

This  is  the  Output  Feedbacic  mode  of  operation,  its  object  identifier  and  parameters  are: 


desOFB  ALGORITHM 
PARAMETER  FBParameter 
: :=  {algorithm  8} 

The  parameters  are  needed  to  specify  an  iV  and  the  number  of  feedbacl<  bits. 

tills  mode  may  be  used  to  encrypt  muHlple  biooks  where  the  ^rrar  extension  pfopertles  of  DSS* 
CBO     unde$^«l)ie.  A  single  bH  mm  in  fh&  c^ph^ext  will  ca^^se  onliir  a  sin^e  tM  err<^  In  th^ 

7.13.1.4  DES-CFB 

This  is  the  Cipher  Feedbacl<  mode  of  operation.  Its  object  identifier  and  parameters  are 

desCFB  ALGORITHM 
PARAMETER  FBParameter 
: :=  (algorithm  9} 

The  parameters  are  needed  to  specify  an  iV  and  the  number  of  feedback  bits. 

mi3d»mB(jf  be  used  when  the  plal(it«xt  is  made^;»«ilabie  i^ece^  e.8.»  adiaMsr  {d*blt  OFB)  ora  bit 
(1  -bit  CFS)  at « tim^  Tiil$  mode  vii  propd^t^^  a  b^  error  h  piair^  block  Ir^  aii  ^ucoei^^rtjS 
blocks^  end  vM  propaggtte  a  single  bit  error  in  the  dptieirte^d:  imo  a  single4>t  error  In  ^  corre8|)orxfir^ 
10mm  chaKedsresyfssll  ^  prblriQ  oftNeii^ii  b^or  eo  ol output  pie  exact emouni  depsndson  ih^e 
Mlback:3iize)i; 


7.13.1.5  DES-MAC 

DES-MAC  is  a  Message  Authentication  Code  algorithm  (cryptographic  checl<sum)  based  on  the  DES||iii|i| 

It  is  specified  in  PIPS  113  [s]  and  is  equivalent  to  the  binary  mode  defined  in  ANSI  X9.9-1986  [tj.  Its  object 
identifier  and  parameter  are: 
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desMAC  ALGORITHM 
PARAMETER  MACParameter 
::=  {algorithm  10} 

The  parameter  Is  needed  to  specify  the  MAC  length  in  bits. 

DES-MAC  is  equivalent  to  DES-CBC  using  an  all  zero  Initialization  Vector  (IV),  with  all  but  the  last 
cipher  output  block  discarded.  Separate  keys  (where  one  may  simply  be  a  variant  of  the  other)  should 
be  used  if  both  DES-CBC  encrypting  and  MACing  the  same  data. 

Editor's  Note  -  We  need  to  include  the  reference  which  specifies  the  vulnerability  when  the  same  key 
is  used  to  DES-CBC  encrypt  and  MAC  the  same  data,  and  recommends  the  use  of  separate  keys. 


The  8l0orlthm  ^  fnci^t'Deerypt'Ertcrypt  iWDtf&\  mode,  def&wd  by  Iaf|  for  encryption  and 
<|$eryD^  Vsrith  D»k^4>f  044>it  im^*  «ilfl^t  ^  umi  for  key  or  MAC  ertoryplJor*  wb$«  symmetric  key 
mttsaipmttrtt  £s  ^sv^oyed^.  CThe  mechanism  h  «Qb|ect  to  i^a  same  constraints  a&  DES  ECS,  but  is 
'  ^;^«ia8y  i^^mm^  <3iveft  the  i^lr  of  k«iy^^  the  H  ^rioig^^^^H^kst  key^ 
'  ^^^^  th«  ai»cb»d  key,  mS^  anelphered  jaiQaln  with  the  first  key 
imkmd  Ibr  <febivi>^oa*  thet  both  key*  ero  the  ^ama.  Ilie ' 
B&Hlift  eneryptioR  u»j(ii«!:i^4lr)9[fe  key.  The  key  mey  be  represented  as  a  almgle  l;^8-bit  string  wfth  the 
the  Itrit  l^ey  dud  the  la$t  04  bit^  b^lno  the  $e<J<3rtd  key* 


RC^-CBC  ^  ji  s^TMifatrte  btock  eocryptiCBn  ^oorlthtOx  It  l«  propo'etav  to  RSA  Data  Securtt^rftKC  anil 
il|lc^i$e  ft^m  t^m  h  *$<iBtred  to  u$e  tt»e  algorithm-  The  aiflorithm  ui$ae  an  a-byte  key  and  operates 
m  m  B-byte  fatockr  wWi  cipher  btodc  chiiinlna  aa  DESx  The  recommencted  padd'm^  \s  as  described 
llhove  ^or  DCS-CeC'.  the  fM  I^OCkie  i»dd$<l  to  aft  S-^yte  boundary  by  appi^no  8  *  (n  mod  8]  bytes^ 
^h  ha\Ang  the  value  S  -  ftti"««id  Bh  where  Is  the  total  mrn^f  of  bytes  b^ng  ertcrypted .  The  speed 
Itf'oon^able  to  0£5. 

M*  i '1^P^t%V  s<ne«b«c-^oay(a)  tJSC640)  t»A<a»iill3B49>  encrypt lotAXgoirltttfa^ 3)  a>^ 
^-^csgrapatrawster  t<«  {iv,  «8QT?s»of  wrsioti  Rcaveireion,  iv}| 
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7.14  ASN.1 


7.14.1     Distinguished  Encoding  Rules 

In  order  to  allow  verification  of  digital  signatures  produced  by  the  SIGNED  and  SIGNATURE  MACROs 
of  [IS09594-8],  it  is  necessary  to  define  a  set  of  distinguished  encoding  rules  to  produce  an 
unambiguous  encoding  of  a  given  abstract  syntax  value.  [IS09594-8]  defines  a  number  of  such 
encoding  rules  (8.7),  but  is,  unfortunately,  underspecified  in  the  following  areas: 

a)  Ordering  of  SET  OF  components; 

b)  Handling  of  unused  trailing  zero  bits; 

c)  Invocation  and  designation  of  new  character  sets  in  some  of  the  character  string  types. 
The  following  rules  remove  these  ambiguities: 

a)  The  [IS09594-8]  distinguished  encoding  rules  are  always  used; 

b)  For  SET  OF  types,  components  are  sorted  into  ascending  order  of  the  distinguished 
encodings  of  the  components; 

c)  For  BIT  STRINGS  with  unused  trailing  bits,  if  the  type  definition  that  specifies  the  bits  have 
significance,  then  they  are  included  in  the  encoding;  otherwise  they  are  not; 

d)  For  those  character  strings  which  allow  it,  escape  sequences  are  generated  to  invoke  and 
designate  new  register  entries  only  when  the  register  entry  for  the  character  currently  being 
encoded  is  different  from  that  currently  designated  for  GO,  CO,  or  CI .  All  designations  shall 
be  into  GO  or  CO.  (It  is  assumed  that  all  characters  have  entries  in  the  ISO  Registry  of  Coded 
Character  Sets.) 
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NOTE  -  Rules  b,c,  and  d  are  taken  from  (ISO/CD8825-31  (Nov.  1 990),  the  ASN.  1  Distinguished  Encoding 
Rules.  Other  features  of  (ISO/CD8825-3],  which  conflict  with  [IS09594-81  (e.g.,  length  encoding  for 
constructors),  are  NOT  used  by  this  lA. 

It  is  recommended  that  whenever  the  SIGNED  or  SIGNATURE  macro  is  to  be  applied  to  an  object,  the 
object  should  be  transferred  in  its  distinguished  encoded  form.  In  this  way,  when  the  resources 
required  to  encode  or  decode  an  object  exceed  the  resources  required  to  apply  the  SIGNED  or 
SIGNATURE  macro,  a  receiving  entity  may  apply  the  macro  immediately,  thus  realizing  enhanced 
performance.  However,  if  the  macro  application  is  unsuccessful,  the  object  must  be  distinguished 
encoded  and  the  macro  re-applied  to  determine  its  actual  success  or  failure. 


8    Lower  Layers  Security 
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9     Upper  Layers  Security 

This  clause  addresses  the  provision  of  security  services  in  the  Upper  Layers.  The  Upper  Layers 
Security  Model  specifies  the  interactions  among  the  Upper  Layers  in  providing  and  using  security 
services  [ISO/CD10745]. 


9.1      Security  iVIechanisms 


9.1.1       Peer  Entity  Authentication 

ACSE  authentication  extensions  [ISO8649][ISO8650/1  ]  support  two-way  authentication  through  the 
definition  of  a  new  functional  unit.  When  this  functional  unit  is  employed,  additional  parameters  are 
provided  by  the  A-ASSOCIATE  service  to  indicate  this  requirement  and  convey  authentication 
information  between  entities.  The  ASN.1  definition  for  this  information  is  given  below: 


from  (1808650/11: 

Authontiootion  !!-  SEQUENCE  (  

moohoniom  nomo  [01  IMPLICIT  OBJECT  IDENTIFIER  OPTIONAL, 


M9cN«u^sm^m«  am  OBJECT  lOENTtRB^ 

fiisM  sNsil  be  preeem  if  authentication-valite  Is  of  type  AHY. 

^uthentication-value  CHOICE  { 

charstring  [01  IMPLICIT  GraphicString, 

bitstring  [11  IMPLICIT  BIT  STRING, 

external  [21  IMPLICIT  EXTERNAL, 

other  [31  ANY  DEFINED  BY  m-  Defined  by  Mechanism-name  }4 

»-Thft  sd»tract  syntax  of  au^entlcation-vaiue  is  determined  by  idie  authentication-mechanism 
>^$«d  <Mrm  ^$$0Ci9ttt»ft  $^t$bli^ifn«f)t*  TH^  ^vtte^i^0A^<^nt$m  i$  eithi^  expiloitty 
Hienoted  by  the  OBJECT  (DENTiFtEH  value  ior  Mechanism-name,  or  it  Is  know  impMth  by 

«gr«$m$^  between  tM  oiitmrmtfuii^^ting  p«rtner$*  If  ''^^^r*^   ah^a^  thai) 
P*li$iK^i^m*<iam»'^  must  be  present  In  accordance  wiH)  ISO  8824. 


Figure  1 — A-ASSOCIATE  Authentication  Information 


These  agreements  define  the  following  mechanisms  for  use  with  this  ACSE  functional  unit: 


26 


PART  1 2  -  SECURITY  December  1 992  (Stable) 

simple-strong  authentication  mechanism. 
9.1.1.1        Simple-Strong  Authentication 


9.1.1.1.1  Operation 

The  operation  of  the  simple-strong  authentication  mechanisms  are  based  upon  [IS09594-3]  and 
[IS09594-8]  standards.  The  sending  system  is  the  entity  requesting  authentication  of  its  identity,  and 
the  receiving  system  is  the  entity  performing  the  authentication.  The  sending  system  supplies  data 
for  the  ACSE  authentication  field  of  the  A-ASSOCIATE  primitive.  The  receiving  ACSE  obtains  the 
\  ACSE  authentication  data  from  the  A-ASSOCIATE  PDU,  and  it  performs  the  authentication  check.  If 
the  check  is  successful,  the  association  formation  succeeds  or  fails  depending  upon  other 
circumstances  and  parameters.  The  use  of  the  ACSE  authentication  fields  support  both  the  simple  and 
strong  credentials  variants  of  the  [IS09594-8]  authentication  exchanges. 

Certificates  for  use  with  strong  authentication  must  be  compatible  with  [IS09594-8]. 
Certificates  procured  for  use  with  Internet  Privacy  Enhanced  Mail  lullvllwllx]  are  completely 
compatible  with  [IS09594-8]  and  may  (subject  to  licensing  restrictions)  be  used  by  the  strong 
authentication  mechanism.  However,  Privacy  Enhanced  Mail  uses  only  a  subset  of  the 
suggested  [1809594-7]  name  forms,  and  might  not  support  certain  name  forms  of  interest 
to  specific  OIW  applications.  Examples  include  Application  Entity  names  and  certain  name 
forms  defined  by  the  North  American  Directory  Forum  in  NADF-123  [y]. 

9.1.1.1.2  Data  Structure 
Mechanism  Name 

The  following  is  the  ASN.1  description  of  the  authentication  data  structure  for  simple  or  strong 
authentication: 

simple-strong-auth-mechanism  OBJECT  IDENTIFIER  ::=  {iso  (1) 
identif ied-organization  (3) 
oiw  (14) 
secsig  (3) 

authentication-mechanisms  (3) 
simple-strong- identity-authentication  ( 1 ) 

} 

Authentication  Value 

The  authentication  value  is  conveyed  in  the  other  option  of  the  authentication-value  field  of  ACSE 
authentication. 

Authentication-Value  ::= 

SEQUENCE  OF  DirectoryAbstractService . Credentials 
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This  data  type  is  defined  in  ASN.1  module  DirectoryAbstractService  of  [IS09594-3]  as  modified 
through  resolution  of  Directory  Defect  Report  Numbers  9594/052  and  063.  The  semantics  of  all  fields 
are  as  specified  in  clause  8.1 .2.1  of  [IS09594-3]. 

The  Authentication-Value  is  defined  as  a  SEQUENCE  because  it  is  permitted  to  pass  credentials  for 
multiple  entities  in  the  authentication  value.  It  is  the  responsibility  of  the  application  to  determine  the 
specific  meaning  and  use  of  multiple  credentials  in  such  a  case.  It  is  anticipated  that  specific 
applications  (e.g.,  Network  Management)  would  provide  specifications  for  handling  multiple  credentials 
within  their  own  clauses  of  this  Part. 

This  authentication  mechanism  may  employ  any  registered  authentication  algorithm;  however,  it  is 
recommended  that  the  algorithms  identified  in  clause  7  be  used. 


9.1.1.1.3  Options 

For  the  Simple  Credentials  option  of  Credentials,  the  following  agreements  apply.  Conforming 
implementations  are  not  required  to  employ  the  OPTIONAL  validity  sequence  of  the  SimpleCredential 
data  element.  Receiving  implementations  that  do  not  employ  the  validity  sequence  must  reject  an 
authentication  value  which  does  contain  this  sequence.  Conforming  implementations  shall  employ  the 
optional  password  field  of  the  SimpleCredential  data  element. 

Note  that  the  password  may  be  hashed  using  one  way  functions  and  the  other  validity  fields. 
Password  is  either  cleartext,  Protectedl  or  Protected2  according  to  [IS09594-8]. 


9.1.1.2        External  Authentication  Mechanisms 

Externally  defined  authentication  exchanges  may  employ  the  external  [2]  option  of  the  authentication- 
value  field  of  ACSE  authentication.  In  this  case  it  is  recommended  that  the  mechanism-name  be 
omitted,  with  the  particular  mechanism  in  use  being  implied  by  the  abstract  syntax  identified  in  the 
external  construct. 


9.1.1.2.1  Kerberos  Version  5 


One  instance  of  an  external  authentication  mechanism  is  the  Kerberos  mechanism  defined  in  [z].  The 
Kerberos  specification  assigned  the  following  object  identifier  to  an  abstract  syntax  suitable  for  use  j 
in  this  way: 


[TBD] 
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10  Message  Handling  System  (MHS)  Security 

All  current  MHS  security  relevant  text  appears  In  Part  8,  clause  1 0. 


1 1  Directory  Services  Security 


12  Networic  Management  Security 

This  clause  outlines  an  approach  to  providing  security  services  for  081  Networic  Management.  The 

goals  of  this  approach  are  to  provide  security  in  a  manner  that  is  simple  and  straight-forward  to 
j  implement,  and  to  avoid  any  unnecessary  computational  and  managerial  overhead.  The  approach  also 
||    takes  into  consideration  the  need  for  different  levels  of  security  services  within  different  network 

management  domains,  and  the  near  term  requirement  for  interoperability  of  network  management 

entities  over  heterogeneous  network  types. 


!    12.1  Threats 

For  the  purpose  of  discussion,  threats  are  divided  into  two  categories:  primary  and  secondary  threats. 
Primary  threats  are  those  considered  to  be  applicable  to  the  full  range  of  network  management 
implementations,  while  secondary  threats  are  considered  to  be  applicable  to  the  more  limited  range  of 
'     highly  secure  implementations. 

The  primary  threats  to  be  protected  against  are  the  following: 

]  a)  The  masquerading  of  a  manager  or  agent  entity; 

j 

I  b)  The  fabrication  or  modification  of  Common  Management  Information  Protocol  (CM IP)  data 

units. 

!     By  countering  primary  threats,  disruption  of  network  management  services  by  the  casual  user  can  be 
avoided. 

i     The  secondary  threats  to  be  protected  against  are  the  following: 
a)  All  primary  threats; 


b) 


The  disclosure  of  CM  IP  data  units; 


c) 


The  replay,  reflection,  reordering,  insertion,  or  deletion  of  CMIP  data  units. 
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12.2    Security  Services 


12.2.1     Basic  Security  Services 

The  security  services  required  to  counter  primary  threats  are: 

a)  Peer  entity  authentication; 

b)  Data  origin  authentication; 

c)  Connectionless  integrity. 

Peer  entity  authentication  is  to  occur  during  the  establishment  of  an  application  association.  If  the 
association  is  successfully  established,  the  underlying  security  mechanism  provides  information  that 
is  subsequently  used  in  data  origin  authentication.  There  the  information  may  be  included  in  or,  in 
some  other  way,  transform  the  data  units  of  subsequent  exchanges  so  that  they  can  be  identified  as 
originating  from  an  authenticated  entity.  Both  authentication  security  services  are  to  be  provided  at 
the  application  level  of  the  protocol. 

Connectionless  integrity  insures  that  data  units  originating  from  an  authenticated  source  are  not 
modifiable  without  detection.  When  combined  with  a  strong  data  origin  authentication  mechanism, 
the  ability  to  fabricate  new  data  units  is  also  countered.  Connectionless  integrity  may  be  provided  at 
either  the  application  level  of  the  protocol  or  within  one  of  the  lower  levels  of  the  protocol  (i.e., 
transport  or  network). 


12.2.2     Enhanced  Security  Services 

The  security  services  required  to  counter  secondary  threats  are: 

a)  All  basic  security  services  with  the  possible  exception  of  connectionless  integrity; 

b)  Connectionless  confidentiality; 

c)  Connection  integrity  with  or  without  recovery. 

Both  connectionless  confidentiality  and  connection  integrity  may  be  provided  at  either  the  application 
level  of  protocol  or  within  one  of  the  lower  levels  of  protocol.  The  latter  provision  is  assumed  here. 
Enhanced  security  services  are  not  discussed  further  in  this  note,  but  to  be  issued  as  a  requirement 
for  the  lower  layer  protocol  and  service  standards,  and  according  to  functional  standards  to  be 
developed. 
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12.3.1  Peer  Entity  Authentication 

Peer  Entity  Authentication  will  use  the  ACSE  authentication  mechanism  and  associated  data  types  as 
defined  in  clause  9  of  this  Part  of  the  lAs.  The  specific  authentication  mechanism  to  be  supported  is 
the  Simple-Strong  Authentication  defined  in  9.1 .1 .1 . 

Support  of  ACSE  authentication  is  optional. 

12.3.2  Connectionless  integrity 

Editor's  Note  •  Proposed  text  for  this  clause  appears  in  WIA  Part  12,  clause  12.3.2. 
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Annex  A  (normative) 
ISPICS  Requirements  List 


32 


PART  12 -SECURITY 


December  1992  (Stable) 


Annex  B  (normative) 


Errata 

Table  2  •  SIA  Part  12  changes 


NO.  OF  ERRATA 
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REFERENCED  DOCUMENT 

CLAUSE 

NOTES  1 
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Annex  G  (informative) 
EIGamal 

The  information  in  this  subclause  includes  a  tutorial  description  of  the  EIGamai  scheme  for  digital 
signature  using  the  notation  defined  in  the  Directory  Documents,  [IS09594-81.  It  is  intended  that  much 
of  the  tutorial  information  provided  in  this  subclause  will  be  moved  to  the  security  agreements 
sometime  in  the  future. 


G.1  Background 

The  EIGamai  digital  signature  scheme  is  based  on  earlier  work  done  by  Diffie  and  Hellman  [b]  in  which 
it  was  suggested  that  a  likely  candidate  for  a  one-way  function  is  the  discrete  exponential  function 


where  x  is  an  integer  between  1  and  p-1  inclusive,  where  p  is  a  very  large  prime  number,  and  where 
a  is  an  integer  such  that  1  ^a^p  and  {a  mod  p,  cr^  mod  p,      (f^  modp}  is  equal  to  the  set  (1,  2, 
p-1}.  In  algebraic  terminology,  such  an  a  is  called  a  primitive  element.  References  on  the  topic  of 
primitive  roots  and  elements  are  [aa]  and  [ab]. 

Now,  in  the  real  number  system,  if  y  =  a*,  then  by  definition  of  the  logarithm  we  can  solve  for  x  using 
^  =  log,(/).  The  same  idea  extends  to  solving  eq  (1)  for  x  so  that  inverting  Y(x)  requires  calculating 
discrete  logarithms.  The  reason  Diffie  and  Hellman  suspected  eq  (1)  is  one-way  is  that  for  suitable  p, 
it  is  computationally  difficult  to  invert  ^(x).  According  to  the  current  state  of  the  art,  computing  discrete 
logs  for  suitable  p  has  been  found  to  require  a  number  of  operations  roughly  equivalent  to 


where  b  is  the  number  of  bits  in  p,  and  c  is  estimated  at  c  =  .69  according  to  [ac].  This  can  be 
compared  to  only  about  2  logj  p  multiplications  for  discrete  exponentiation.  If  in  fact  the  best  known 
algorithm  for  computing  discrete  logs  is  near  optimal  then  Expression  (2)is  a  good  measure  of  the 
problem's  complexity  (for  a  properly  chosen  p)  and  the  discrete  exponential  function  has  all  the 
qualities  of  a  one-way  function  as  described  by  Diffie  and  Hellman. 


G.2      Digital  Signature 

Private  Key:  X,  denotes  the  private  key  for  user  X.  X,  is  a  randomly  chosen  integer  which  user  X  keeps 
secret. 

Public  Key:  Xp  denotes  the  public  key  for  user  X  and  is  calculated  using  the  corresponding  private  key 
such  that 


/(jc)"a'(mod/>) 


(1) 


exp(v/cSnfc) 


(2) 


Xp-a*'(moc(p) 


(3) 
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where 

a)  p  is  a  prime  satisfying  the  requirements  listed  in  12.2.2.4. 

b)  a  is  a  primitive  element  mod  p. 

c)  Note  that  p  and  a  could  be  used  globally,  but  because  they  should  be  easily  changeable  (see 
12.2.2.4  for  information  about  why  these  two  parameters  should  be  easily  changeable)  it 
would  probably  be  preferable  for  each  user  to  choose  his/her  own  p  and  a.  If  users  choose  their 
own,  then  p  and  a  must  be  made  available  to  the  recipient  for  use  in  the  signature  verification 
process. 

Signing  Procedure:  Suppose  user  A  wants  to  sign  a  message  intended  for  recipient  B.  The  basic  idea 
is  to  compute  a  two  part  signature  {r,  s)  for  the  message  m  such  that 

a*<-)-(A/;)'r'(modp) 

where  /?  is  a  one-way  hash  function. 
Compute  the  signature  (r,  s)  as  follows. 

a)  Choose  a  random  number  k,  uniformly  between  0  and  p-1  such  that  k  and  p-1  have  no 
common  divisor  except  1  (i.e.,  gcd(Ar,p-1)  =  1). 

b)  Compute  r  such  that 

r-o*(modp)  <5) 

c)  Use  r  to  solve  for  the  corresponding  s  as  follows. 

1 )  rewrite  eq  (4)  using  eq  (5)  and  the  definition  of  the  public  key  to  get 

a*(-)-«<^>a*'(mocb) 
Combining  exponents,  get 

«»(-),al*>**»(modp) 

eq  (7)  implies  that 

A(»i)-(/l^r+iks(modp-1)  <8) 

Note  that  eq  (8)  has  a  single  solution  for  s  because  k  was  chosen  such  that  gcd(A:,p- 

1 )  =  1 .  See  [ad]  for  supporting  theorem. 

2)  now  solve  for  s  and  get 

5-/(Mm)-(Ajr)(modp-1)  <9J 
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where  /  is  computed  such  that  k  *  /  m  1  (mod 
The  EIGamal  signature  Is  comparable  In  size  to  the  corresponding  RSA  signature. 


G.3  Verification 

The  recipient  receives  Ap,  m,  r,  s,  a,  and  p  and  computes  both  sides  of  eq  (4)  and  then  compares  the 
results. 


G.4      Known  Constraints  on  Parameters 

The  following  list  of  constraints  is  the  result  of  a  search  of  current  literature  and  may  not  be  complete: 

a)  p  must  be  prime; 

b)  p  must  be  large. 

Note  that  Expression  (2)  can  be  used  to  speculate  on  the  level  of  security  afforded  by  crypto 
systems  based  on  the  discrete  log  problem.  Breaking  the  EIGamal  scheme  has  not  been  proven 
to  be  equivalent  to  finding  discrete  logs,  but  if  we  assume  equivalence  then  we  can  estimate 
how  large  p  should  be  for  a  desired  level  of  security. 

For  instance, suppose  we  wanted  to  use  Expression  (2)  to  decide  how  large  p  should  be  so  that 
we  can  be  reasonably  sure  the  system  cannot  be  broken  (using  the  best  known  algorithm)  in 
a  practical  amount  of  time.  To  be  on  the  conservative  side,  we  decide  we  want  to  protect 
against  a  special  purpose  machine  that  can  perform  10^^  operations  per  second.  Specifically, 
we  want  to  know  how  large  p  should  be  so  that  such  a  machine  would  take  at  least  one  year 
to  break  the  system. 

in  one  year,  the  hypothetical  machine  can  perform  3x10^^  operations.  To  find  the  size  of  the 
desired  p,  solve  the  following  equation  for  b. 

exp(v^Sn^)=3x1022 

We  get  This  is  the  number  of  bits  in  the  desired  p.  So,  the  magnitude  of  the  desired 

p  is  about  2"*"  which  is  roughly  266  x  10^"*. 

Hence,  to  be  reasonably  sure  of  attaining  the  desired  level  of  security,  we  find  a  prime  number 
greater  than  266  x  10^"°  which  satisfies  all  the  other  criteria  listed  in  this  subclause.  Our 
confidence,  however,  is  strictly  based  on  the  assumption  that  breaking  EIGamal  is  as  difficult 
as  finding  discrete  logs  and  the  assumption  that  the  best  known  algorithm  for  finding  discrete 
logs  is  near  optimal. 

c)  p  should  occasionally  be  changed.  This  requirement  is  discussed  in  [ae]  and  is  related  to  the 
discovery  of  new  algorithms  for  computing  discrete  logarithms  in  GF{p). 
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d)  p-1  must  have  at  least  one  large  prime  factor.  This  requirement  is  discussed  in  [ae]  and  is 
imposed  by  the  Sllverman-Pohlig-Hellman  algorithm  p  which  computes  discrete  logarithms  in 

GF{p)  using  on  the  order  operations  and  a  comparable  amount  of  storage,  where  r  is  the 
largest  prime  factor  in  p-1 . 

e)  p  should  not  be  the  square  of  any  prime.  A  subexponential-time  algorithm  for  computing 
discrete  logarithms  in  GF{p^)  has  been  found.  See  [af]for  details. 
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 PARAMETER  NULL 

 — [Qlgogithm  4} 

dooECB  ALGORITHM 

 PARAMETER  NULL 

 11-  {algogithm  6) 

dooGBC  ALGORITHM 

 PARAMETER  CBCParamotor 

 i-t-- — {algogithm  7) 

CBCParamotor  t i -  IV 

dooOFB  ALGORITim 

 PARAMETER  FSPagomotog 

 »-•— — [algorithm  8) 

dooCFB  ALCORITim 

 PARAMETER  FBPagamotog 

 1 1-  {algorithm  9) 
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Part  14  -  Virtual  Terminal 


0  Introduction 

The  OSI  Implementors'  Workshop  Virtual  Terminal  (VT)  SIG  is  making  implementation  agreements  for  the 
OSI  Basic  Class  VT  Service  and  Protocol.  ISO  9040  and  ISO  9041. 

These  Implementation  agreements  fall  Into  the  following  categories: 

Functbnallty  to  be  implemented,  i.e..  functtonal  units,  etc. 

Identification  and  specification  of  VT  profiles  to  be  supported  by  conforming  implementations. 
Agreements  with  regard  to  implementatk>n  Issues  not  specified  in  ISO  9040  and  ISO  9041. 
Resolution  of  protilems  with  ISO  9040  and  ISO  9041  kJentified  during  implementation. 
Statement  of  requirements  to  meet  conformance  to  these  agreements. 

1  Scope 

1 .1  Phase  la  agreements 

The  Telnet  profile  Is  intended  to  support  the  following  usage: 

a)  a  simple  line  at  a  time  or  character  at  a  time  dialogue; 

b)  an  application  level  gateway  supporting  internet  Telnet  and  ISO  VTP  interoperation. 

The  Transparent  profile  supports  the  exchange  of  uninterpreted  sequences  of  characters.  This  includes 
support  of  VT-users  who  wish  to  control  terminals  directly  through  the  use  of  embedded  control  characters 
and  escape  sequences. 

1 .2  Phase  lb  agreements 

The  Forms  profile  is  Intended  to  support  fomns-based  applications  with  local  entry  and  valkJation  of  data  by 
the  temilnal  system.  This  profile  is  now  aligned  with  the  EWOS  VT  EG  Functional  Standard. 
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1 .3      Phase  II  agreements 

The  X.3  profile  supports  functionality  similar  to  the  CCITT  recommendations  and  could  be  used  to  Implement 
an  X3  to  ISO-VT  gateway. 

The  S-mode  Paged  Application  profile  Is  Intended  to  provide  a  Forms  capability  for  the  existing  base  of 
block  mode  termiruds.  It  contains  a  subset  of  the  functionality  provided  by  the  Forms  profile. 

See  Working  Agreements  regarding  other  Phase  II  profiles. 


2    Normative  references 

ISO  9040:1990,  Information  technology  -  Open  Systems  Interconnection  -  Virtual  Terminal  Basic  Class 
Serwce. 

ISO  9041-1:1990,  Information  technology  -  Open  Systems  Interconnection  -  Virtual  Terminal  Basic  Class 
Protocol  -  Part  1:  Specification. 

ISO  9834-4,  Information  technology  -  Open  Systems  Interconnection 

-  Procedures  for  the  Operation  of  OSI  Registration  Authorities 

-  Part  4:  Register  of  VTE  Profiles. 

ISO  9834-4,  Information  technology  -  Open  Systems  Interconnection 

-  Procedures  for  the  Operation  of  OSI  Registration  Authorities 

-  Part  5:  Register  of  VT  Control  Object  Definitions. 


3  Status 

This  version  of  the  agreements  was  completed  In  December  1991. 


3.1      Status  of  phase  la 

Phase  la  of  the  VT  Agreements  was  stabilized  May  5, 1988.  This  phase  covers  the  Telnet  and  Transparent 
profiles.  No  future  enhancements  will  be  made  to  this  phase. 


3.2      Status  of  phase  lb 

Phase  lb  of  the  VT  Agreements  was  first  stabilized  December  16, 1 988.  This  phase  covers  the  Forms  profile. 
Alignment  with  EWOS  required  substantial  modifications  which  were  ratified  September  15,  1989. 
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3.3     Status  off  phase  II 

Phase  II  Is  sti  in  progress  and  Includes  the  remaining  prone  work  for  the  Scroll  profle. 

The  S-mode  Paged  Application  Profle  is  being  progressed  as  PDiSP  11187-2  (AVT-23  S-mode  Paged 
AppHcailon  Profle). 

The  X.3  profle  of  pftase  11  \Mas  stablized  December  15. 1969. 

The  Generalized  Telnet  profle  of  phase  II  was  stablized  December  13. 1991. 

It  is  intended  tliat  Phase  II  agreements  be  compatit)le  with  Phase  I  agreements. 

4  Errata 

EdNor't  Note  •  'Defect  Report"  material  may  be  induded  here,  inducting  versions  of  implementor  agreements 
to  which  it  applies. 
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Table  1  -  Technical  errata 


06/90-1 

Forms  Profile.    The  "FEICO  Update  Syntax**  ASN.l  comment  which 
follows  the  definition  of  the  PriValue  type  was  corrected  to 
support  multi-octet  repertoires. 

06/90-2 

Forms  Profile.    The  descriptive  text  for  the  Field  Entry 
Instruction  Violation  FEE  was  corrected  to  indicate  that  both 
an  entry-control  index  emd  a  FEPR  index  are  required  to 
identify  the  FEPR  concerned. 

06/90-3 

Forms  Profile.    The  descriptive  text  and  update  syntax  for  the 
name  and  an  index  are  required  to  identify  a  FEIR. 

06/90-4 

Forms  Profile.    The  update  syntax  for  the  writeString  FER  was 
ccsTTf^c^Y^A  Yd  alion  wi  f"h           dp^tfTi  ni"  i        'hpxt   for  ♦■his  PER 

06/90-5 

Forms  Profile.     The  descriptive  text  for  the  repertoire 
assignment  profile  argument  was  corrected  to  properly  identify 
the  default  value  as  the  GL  set  ISO  2375  Reg.  No.  6  (ASCII). 

06/90-6 

Forms  Profile.    The  concept  of  a  **current  keystroke"  was 
inserted  into  the  definition  of  the  FEICO  to  remove  eunbiguity 

were  redefined. 

12/91-1 

Tplnpt   Prrifilp     Chunn^  v— aVisir>l iit"P  valiip  from  "no"   to  "vPS  " 

03/92-1 

Generalized  Telnet  Profile.  Add  conformance  statement 
regarding  the  requirement  to  accept  negotiation  of  Suppress 

03/92-2 

Generalized  Telnet  Profile.  Rework  Definitive  Note  8, 

tSJw^CiilU  X  11^      Lilt?     X  tS^tSX  L\./X  X         lltf         1*  X  CI  L  X  KJll     V^iiCl^Cll.'  X  XXLjf                 CIX  x^w 

negotiation  for  the  use  any  one  of  a  number  of  non-binary 
repertoires. 

03/92-3 

X.3  Profile.  Correct  processing  of  terminal  break  so  that  it 
aligns  with  the  procedures  of  ccitt  X.29. 

12/92-1 

Generalized  Telnet  Profile.    Rework  Definitive  Note  8,  to 
clarify  repertoire  negotiation  capability. 

12/92-2 

Generalized  Telnet  Profile.    Add  Informative  Note  4,  to 
clarify  situations  where  repertoire  negotiation  capability 
beyond  switching  to  binary  would  be  used. 

12/92-3 

Generalized  Telnet  Profile.    Remove  item  C  from  Definitive 
Note  3. 

12/92-4 

Generalized  Telnet  Profile.    Clarify  action  of  VT-BREAK  in 
Informative  Note  3. 
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Table  2  -  Alignment  errata 

06/90- 

•7 

rorms  rroriie.    A  derinitive  note  was  added  to  define  how  the 
host  is  notified  of  the  current  entry  location  when  data  entry 
terminates  and  the  VTE-pareuneter  access-outs i de-fields  has  the  1 
value  "allowed." 

06/90- 

8 

Forms  Profile.    Three  font-assignment  profile  arguments  were 
added  to  accomodate  INTAP  requirements.  | 

09/90- 

1 

Forms  Profile.    The  emphasis  subattribute  "h"  was  added  with 
values  "P"  (Framed)  and  "C"  (Encircled).  | 

09/90- 

2 

Telnet  Profile.    Four  editorial  comments  were  incorporated  to 
align  with  the  corresponding  EWOS  Functional  Standard. 

Table  3  -  Editorial  errata 


06/90- 

9 

Forms  Profile.    Two  definitive  notes  were  added  to  clarify  the 
secoiiuary  akbriDULes  comparison  mecnanisms  tor  tne  FEls  and 
FECs  that  test  equality  of  characters. 

06/90- 

•10 

Forms  Profile.    A  definitive  note  was  added  to  clarify  the 
effect  of  associating  multiple  Character-oriented  FEIs  of  the 
same  type  with  the  saune  field. 

06/90- 

•11 

Forms  Profile.    An  introductory  paragraph  in  the  section  "Field 
Entry  Condition  Definitions"  was  rewritten  for  clarification. 

06/90- 

•12 

Forms  Profile.    The  descriptive  text  for  the  Write  String  field 
entry  reaction  was  modified  to  indicate  precisely  how  and  where 
the  associated  string  is  to  be  written. 

09/90- 

•3 

X3  Profile.    The  reference  to  COs  P3  and  P4  contained  in 
comments  relating  to  DEVICE-1  were  corrected  to  reference 
elements  3  and  4  of  the  PAD  CO. 

12/90- 

1 

X3  Profile.  Changes  were  made  to  correct  editorial  errors 
discovered  during  the  progression  of  the  EWOS  X3  Profile 
Functional  Standard. 

09/91- 

1 

Scope,  Status,  and  References  clauses  were  updated. 

09/92- 

•1 

Status  clause  was  updated. 

12/92- 

1 

Scope  and  Status  clauses  were  updated. 

12/92- 

2 

Headings  and  Table  entries  were  updated. 

12/92- 

3 

S-mode  Paged  Application  profile.    Created  Section  8.6  to 
reference  the  S-mode  Paged  Application  Profile. 

12/92- 

4 

Telnet-1988  profile.    A  note  was  added  to  clarify  the  future  of 
the  profile. 
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5  Conformance 

Conformant  VT  implementations  are  required  to  support  the  ISO  9041  Clause  13  requirements  plus  the 
additional  conformance  requirements  identified  below. 

Table  4  shows  conformance  status  for  VT  facilities  which  are  optional  in  the  ISO  VT  standard.  The  terms 
used  in  the  figure  are  defined  as  indicated  below: 

a)  "Mandatory"  indicates  that  the  facility  must  be  provided  by  all  implementations  which  conform 
to  these  agreements; 

b)  "Optional"  indicates  that  the  VT  fecility  is  not  required  to  meet  minimum  conformance 
requirements  but  has  been  identified  as  providing  additional  useful  capabilities; 

c)  'Profile  Dependent"  indicates  that  the  requirement  for  the  facility,  if  any,  is  included  in  the  profile 
definitions; 

d)  "Not  Addressed"  indicates  that  the  VT  facility  is  outside  the  scope  of  these  agreements. 


Table  4  -  Conformance  Status  for  VT  Facilities 


C<m£oraance  Status 

Mandatory 

Optional 

Profile 
Dependent 

Not 
Addressed 

Switch  Profile^) 

X 

Multiple  Interaction 
Negotiation^' 

X 

Negotiated  Release^ ^ 

X 

Urgent  Data^) 

Break^) 

X 

Delivery  Control^ ^ 

X 

Enhanced  Access  Rules^) 

X 

Structured  COs^^ 

X 

Blocks^) 

X 

Fields^) 

X 

RIOs^) 

X 

S-mode 

X 

A-mode 

X 

Mode  Switching  Capability 

X 

1)  It  is  not  anticipated  that  new  profiles  will  use  quarantined  delivery 
control. 

2)  Functional  Units. 
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For  each  mode  of  operation  (A-mode  and  S-mode)  which  is  implemented,  the  default  profile  for  that  mode 
as  defined  in  ISO  9040  must  be  supported.  Implementations  that  support  A-mode  must  support  the  A-mode 
default  profile  and  at  least  one  additional  Worlcshop  approved  A-mode  profile.  The  Transparent  profile  does 
not  count  as  an  additional  A-mode  profile.  Implementations  that  support  S-mode  must  support  the  S-mode 
defauCt  profile  and  at  least  one  additional  Workshop  approved  S-mode  profile. 

For  each  profile  Implemented.  VTE  parameter  ranges  or  values  specified  in  the  Wort<shop-agreed  profiie  and 
associated  notes  must  be  supported. 


6  Protocol 


6.1      Protocol  elements 

All  protocol  elements  required  by  the  ISO  9040  VT  l<ernei  and  Break  functional  units  are  selected. 

All  protocol  elements  required  by  the  Switch  Profiie  functional  unit  are  selected  if  this  functional  unit  is  used. 
See  Table  4. 

All  protocol  elements  required  by  the  Urgent  Data  functional  unit  are  selected  if  this  functional  unit  Is  used. 
See  Table  4. 


6.2      Mapping  of  protocol  elements 

Mapping  of  protocol  elements  on  to  ACSE  or  Presentation  Services  Is  as  defined  in  ISO  9041. 


6.3     Protocol  data  unit  structure 

Protocol  data  unit  stmcture  is  as  defined  in  ISO  9041. 


7 


PART  14  -  VIRTUAL  TERMINAL  December  1992  (Stable) 

7    OIW  registered  control  objects 

The  following  Control  Objects  are  used  by  more  than  one  profile.  Some  of  the  CO  parameters  are  left  with 
undefined  values  that  must  be  assigned  by  the  proflie  in  which  the  Control  Object  is  used. 

7.1      Sequenced  Application  (SA) 

This  is  a  Control  object  used  to  convey  signals  from  the  application  to  the  terminal  in  sequence  with  other 
updates. 

7.1.1  Entry  number 

To  be  supplied  by  Registration  Authority. 

7.1.2  Name  of  sponsoring  body 

OSi  implementors'  Workshop  (OiW).  VTSiG. 

« 

7.1.3  Date 

The  date  of  suk>mission  of  this  proposal  is  September  15, 1989. 

7.1.4  Identifier 

oiw-vt-co-misc-sa  OBJECT  IDENTiFiER      {oiw-vt-co-misc  sa(0)} 

7.1.5  Descriptor  value 

"OiW  VT  CO  for  conveying  Sequenced  Application  Signais" 

7.1.6  CO  parameters 

CO-structure  1 

CO-prlorlty  "normal" 

CO-category  "symbolic" 

co-size  11 
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7.1.7      CO  Values  and  Semantics 

Table  5  lists  the  allowed  symbolic  values  together  with  the  integers  used  to  reference  these  values  in  the 
ASN.1  update  syntax  of  ISO  9041: 

 Table  S  -  SA/UA  CO  values  and  semantics. 


Tin 4- ^fggir  Vjiliidb  1 

audible_alara 

0  1 

newl i  ne8_enabled 

1  1 

newl ines_di  sabled 

2  1 

restore 

3 

1  visual.alara 

4 

1  keypad_enabled 

5 

1  keypad.di sabled 

6 

1  keyboard_locked 

7 

1  keyboard_unlocked 

8 

1  device.disconnect 

9 

1  break_8ignal 

10 

The  semantics  of  each  value  must  be  specified  in  the  VTE  profile  which  references  this  CO. 

7.1.8  Additional  Information 

None. 

7.1.9  Usage 

D^ned  in  profile. 
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7.2     Unaequenced  Application  (UA) 

This  b  a  Control  object  used  to  convey  urgent  signals  from  the  application  to  the  termkiai. 

7.2.1  Entry  number 

To  be  supplied  by  Registfation  Authority. 

7.2.2  Name  Of  sponsoring  body 

081  Implemenlors'  Workshop  (OiW).  VTSiG. 

7.2.3  Date 

The  dale  of  submission  of  this  proposal  Is  September  15. 1989. 

72.4  Identifier 

ohv-vt-co-misc-ua  OBJECT  IDENTIRER::=  {oiw-vt-co-misc  ua(1)} 

7.2.5      Descriptor  value 

"OIW  Vr  CO  for  conveying  Unsequenced  Application  Signals" 

7.2.0      CO  parameters 

CO-slruclure  1 
CO-priorty  "urgenT 
COcategory  "symbolic" 
co-size  11 

72.7      CO  values  and  semantics 
SameaslnSA. 
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7.2.9  Usage 

Defined  in  profiie. 

7.3      Sequenced  Terminal  (ST) 

A  Iceyboard  can  generate  many  signals  that  may  be  given  special  meaning  to  tiie  application.  This  CO  is 
general  enough  to  convey  any  l(eyboard  event. 

7.3.1  Entry  number 

To  be  supplied  by  Registration  Authority. 

7.3.2  Name  of  sponsoring  body 

OSI  Implementors  Worlcshop  (01 W),  VTSIG. 

7.3.3  Date 

The  date  of  submission  of  this  proposal  is  Septemt>er  15,  1989. 

7.3.4  Identifier 

olw-vl-co-mlsc-st  OBJECT  IDE^f^FIER  ::=  {oiw-vt-co-misc  st(2)} 

7.3.5  Descriptor  value 

"OIW  VT  CO  for  conveying  Sequenced  Temiinal  Signals" 
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7.3.6      CO  parameters 

CO-stmcture  1 

CO-priority  "normal" 

CO-category  "integer" 

co-size  65535 


7.3.7       CO  values  and  semantics 

The  vaiues  of  the  CO  are  composite,  with  values  from  Jabie  6  giving  meaning  to  the  values  in  the  hex  range 
00-FF  when  added  to  them. 

 Table  6  -  ST/UT  CO  composite  values 


hex  value 

■eaning 

100 

special  key  -  labeled^) 

200 

function  key  depressed 

400 

control  key  depressed 

800 

shift  key  depressed 

1000 

alt  key  depressed 

1)  possible  special  key  values  are 
as  defined  by  the  STCO  ASN.l  module. 

The  special  key  and  the  function  key  are  mutually  exclusive.  If  neither  the  function  keys  nor  the  special  keys 
are  pressed,  then  the  value  in  the  hex  range  00-FF  will  be  that  of  the  normal,  unshifted  code  combination 
generated  by  the  alpha-numeric  key.  Values  in  the  hex  range  00-FF  are  not  valkJ  values  for  the  data  element 
of  this  Control  Object. 

The  control,  shift,  and  alt  keys  may  appear  in  any  combination  with  the  special  or  function  keys. 

The  shift  key  must  occur  in  combination  with  at  least  one  of  the  other  keys  in  the  above  table  to  cause  the 
value  to  ^1  outskJe  the  repertoire  of  the  display  object. 

When  the  special  key  is  depressed,  the  value  of  the  CO  content  will  be  as  given  in  the  ASN.1  module  t)elow 
for  the  value  in  the  hex  range  of  00-FF.  Othenvise,  the  value  will  be  defined  to  be  the  IA5  value  associated 
with  the  key. 
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STCO  DEFINITIONS  ::=  BEGIN 


Key  ::=  INTEGER  { 


break  (0), 

tab  (3), 

carReturn  (6), 

escape  (9), 

multiply  (12), 

rIghtArrow  (15), 

insert  (18), 

deleteLine  (21), 

PageUp  (24). 

pa2  (27), 

statusProcess  (30), 

abortOutput  (33), 

print  (36), 

endOf  Record  (39), 


bell  (1), 

backTab  (4), 

cancel  (7), 

plus  (10) 

divide  (13) 

upArrow  (16) 

delete  (19) 

home  (22) 

PageDown  (25) 

pa3  (28) 
interruptProcess  (31) 

formFeed  (34) 

refresh  (37) 

endOfFile  (40) 


backspace 

lineFeed 

substitute 

minus 

leftArrow 

downArrow 

insertUne 

end 

pal 

help 

terminateProcess 
clear 

systemRequest 
suspendProcess 


(2). 

(5). 

(8), 

(11). 

(14). 

(17). 

(20). 

(23). 

(26). 

(29). 

(32). 

(35). 

(38). 

(41) 


Names  for  combination  keystrokes  are  formed  by  converting  the 
--  initial  letter  to  upper  case  and  prefixing  with  'Ctrl',  'shift'  or 

-  'alt',  which  adds  1024,  2048  or  4096  respectively  to  the  value. 

-  These  prefixes  may  be  used  in  combination  with  one  another  by  a 
--  repetition  of  this  conversion  process,  provided  that  they  appear 

from  left  to  right  in  the  order  'Ctrl',  'shift',  'alt'.  ASN.1 

-  formally  does  not  allow  such  descriptive  additions  but  it  would  be 
--  very  lengthy  to  write  them  all  in  full  -  } 

END   *(STCO  DEFINITIONS)* 

VTE  profile  definitions  may  refer  to  this  module  for  convenience  in  describing  semantics. 


7.3.8       Additional  information 

None. 


7.3.9  Usage 

Defined  in  profile. 
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7.4      Unsequenced  Terminal  (UT) 

Keyboard  events  may  need  to  be  conveyed  urgently,  out  of  sequence  with  normal  updates.  This  CO  is  used 
to  signai  such  events  from  the  terminal  to  the  applicatton. 

7.4.1  Entry  number 

To  be  supplied  by  the  Registration  Authority. 

7.4.2  Name  of  sponsoring  body 

OSi  Implementors  Wort<shop  (OiW),  VTSIQ 

7.4.3  Date 

The  date  of  submission  of  this  proposal  is  September  15, 1989. 

7.4.4  identifier 

oiw-vt-co-misc-ut  OBJECT  iDE^n■iFiER  ::=  {oiw-vt-co-misc  ut(3)} 

7.4.5  Descriptor  value 

"OIW  VT  CO  for  conveying  Unsequenced  Terminal  Signals' 

7.4.6  CO  parameters 

CO-structure  1 
CO-priority  "urgent" 
CO-category  "integer" 
co-size  65535 

7.4.7  CO  values  and  semantics 

Same  as  in  ST. 
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7.4.8  Uaage 

a    OIW  defined  profiles 

These  proMes  are  defined  usino  the  conventions  specified  in  Annex  A  of  iSO  9040. 

8.1     Telnet  profile 

OIWVTE-Profle  Telnet-19e8  (r1.  if2) 

8.1.1  Introduction 

This  profle  provides  support  for  TELMET-lii(e  operation  for  users  of  the  iSO  Virtual  Terminal  Service.  It  is 
based  on  the  IS  version  of  ISO  9040  and  ISO  9041. 

Note:  This  proUe  is  superceded  t)y  the  Generalized-Telnet  profile.  The  text  for  this  profle  ¥i4i  not  be 
maintained  beyorKJ  Its  current  state. 

8.1.2  Association  rsquirementa 
8.1.2.1        Fiiiiclional  units 

The  Urgent  Data  Functional  Unit  is  optional,  but  should  be  used  whenever  avalaUe. 

ai.2.2  Mods 

This  is  an  A-mode  profle. 
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8.1.3       Profile  body 

Display-objects  «  *(double  occurrence)* 
{ 

{ 

display-object-name  =  D,  *(DISPLAY)* 
do-access  =  "WACA", 

dimensions  =  two", 

x-dimension  = 

{ 

x-bound       =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute     =  "yes",       *(See  Definitive  Note  4)* 

x-window      =  profile-argument-r1 

}. 

y-dimension  = 
{ 

y-bound        =  "unbounded", 
y-addressing  =  "higher  only", 
y-absolute     =  "no", 
y-window       =  1 

}. 

erasure-capability  =  "yes", 
repertoire-capability  =  2, 
repertoire-assignment  =  profile-argument-r2, 
repertoire-assignment  =  <ESC>  2/5  2/15  4/2 
}. 
{ 

display-object-name  =  K,  *(KEYBOARD)* 
do-access  =  "WACI", 

dimensions  =  "two", 

x-dimension  = 

{ 

x-bound        =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute     =  "yes",        *(See  Definitive  Note  4)* 

x-window      =  profile-argument-r1 

>. 

y-dimension  = 
{ 

y-bound        =  "unbounded", 
y-addressing  =  "higher  only", 
y-absolute     =  "no", 
y-window       =  1 

}. 
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erasure-capability  =  'yes', 
repertoire-capability  »  2, 
repertoire-assignment  =  profile-argument-r2, 
repertoire-assignment  »  <ESC>  2/5  2/15  4/2 
} 

}. 

Control-objects  =  *(multiple  occurrence)* 
{ 

{  *(SYNCHRONIZE)* 

co-name      =  SY, 
co-access     =  'NSAC, 
CO-category  =  'symbolic', 
co-size        =  1, 
CO-priority     =  "urgent" 

}. 

{  *(DISPLAY-SIGNAL)* 

CO-name      =  Dl, 
co-access     =  "WACA". 
CO-category  =  "boolean", 
CO-size        =  5, 
CO-priority     =  "normal", 
CO-trigger     =  "selected" 

}. 

{  *(KEYBOARD-SIGNAL)* 
CO-name      =  KB, 
co-access     =  "WACI", 
CO-category  =  "boolean", 
CO-size        =  5, 
CO-priority     =  "normal", 

V        CO-trigger     =  "selected' 

}. 

{  *(NEGOTIATION  BY  INITIATOR)* 

CO-name  =  Nl, 

co-access  =  'WACI', 

CO-category  =  "boolean", 

CO-size  =  4, 

CO-priority  =  "normal", 

CO-trigger  =  "selected" 

}. 

{  *(NEGOT!ATION  BY  ACCEPTOR)* 

CO-name  =  NA, 

co-access  =  "WACA", 

co-category  =  "boolean", 

CO-size  =  4, 

CO-priority  =  "normal". 
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CO-trigger 

}. 

{  *(GO-AHEAD)* 
CO-name 
CO-access 
CO-category 
co-size 
CO-priority 
CO-trigger 

} 

}. 

Device-objects  =  *  (double  occurrence)* 
{ 

{ 

device-name  =  DiSPLAY-DEVICE, 
device-dispiay-object  =  D, 
device-default-CO-initial-value  =  1."true",*("on")* 
device-minimum-X-array-lengtli  =  1,*(no  constraint)* 
device-minimum-Y-array-lengtli  =  1,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  NA, 
device-control-object  =  Dl, 
device-control-object  =  GA, 

*(SYNC.NEGOTIATE-ACCEPTOR,DISPLAY-SIGNAL, 
GO-AHEAD)* 
device-default-CO-access  =  "WACA", 
device-default-CO-priority  =  "normal" 

*(other  device  object  parameters  assume  corresponding  DO  values)* 

}. 

{ 

device-name  =  KEYBOARD-DEVICE, 
device-display-object  =  K, 
device-default-CO-access  =  "WACI", 
device-default-CO-priority  =  "normal", 
device-default-CO-initial-value  =  1."true",*("on")* 
device-minimum-X-array-length  =  1,*(no  constraint)* 
device-minimum-Y-array-length  =  1  ,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  Nl, 
device-control-object  =  KB, 
device-control-object  =  GA, 

*(SYNC,NEGOTIATE-INITIATOR,KEYBOARD-SIGNAL, 
GO-AHEAD)* 

*(other  device  object  parameters  assume  corresponding  DO  values)* 
} 


=  'selected* 


=  GA, 
=  "NSAC", 
=  "boolean", 
=  1. 

=  "normal". 
=  "selected" 


18 


PART  14  -  VIRTUAL  TERMINAL  December  1992  (Stable) 

}. 

Type  of  delivery  control  =  "simple-delivery-control." 
8.1.4       Profile  arguments 

n  -  is  used  to  represent  the  line  length  as  the  value  of  VTE  parameter  x-window  for  both  display  objects. 
This  argument  is  mandatory  and  tal<es  a  nonnegative  Integer  value.  This  argument  Is  Identified  by 
the  identifier  for  x-window  for  display  object  D. 

r2  -  is  used  to  designate  the  default  repertoire  for  both  display  objects.  This  argument  Is  optional.  If  not 
present  the  full  US  ASCII  set  is  the  default.  This  argument  Is  Identified  by  the  Identifier  for  repertoire 
assignment  for  the  display  object  D. 


8.1.5       Profile  dependent  control  object  information 

This  profile  does  not  reference  any  Control  Objects  which  are  not  defined  within  this  profile. 


8.1.6       Profile  notes 


8.1.6.1        Definitive  notes 

1.       Booieans  In  the  KB  and  Dl  control  objects  are  used  In  this  profile  to  correspond  to  TELNET 
commands  as  follows: 

 Table  7  -  KB/DI  CO  value  definitions 


Ccmtrol  (X>ject 

Boolean 

TELNET 

DI/KB 

1 

IP 

1  DI/KB 

2 

AO 

DI/KB 

3 

AYT 

DI/KB 

4 

DM 

DI/KB 

5 

BREAK 

The  equivalent  of  a  TELNET  command  is  acliieved  by  selecting  tlie  boolean  that 
corresponds  to  the  desired  TELNET  command.  Selecting  a  boolean  in  the  Dl  or 
KB  control  object  means  setting  the  value  of  the  desired  boolean  to  "true."  The 
usage  of  the  masi<  element  of  the  boolean  update  is  as  specified  in  ISO  9041. 

2.  The  equivalent  of  a  TELNET  SYNCH  command  Is  achieved  by  updating  the  SY  control  object  with 
the  single  symbolic  value  of  "SYNCH"  (which  is  mapped  onto  the  integer  value  1),  and  immediately 
updating  the  Dl  (or  KB)  control  object  selecting  the  DM  boolean.    IP,  AO,  AYT,  or  BREAK 
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commands  may  be  accompani^  by  a  SYNCH  command  by  updating  the  SY  control  object  and 
then  updating  the  Dl  or  KB  control  object  selecting  both  the  DM  and  the  other  desired  boolean. 
When  an  update  to  the  SY  control  object  is  received  subsequent  display  object  updates  are 
discarded  until  an  update  to  the  Dl  or  KB  control  object  is  received  selecting  the  DM  bit.  If  a  VT- 
BREAK  is  received  after  an  SY  CO  update  has  been  received  and  prior  to  the  corresponding  Dl  or 
KB  CO  update  selecting  the  DM  boolean,  the  discarding  of  updates  is  terminated.  This  is  necessary 
because  the  VT-BREAK  may  have  caused  the  Dl  or  KB  CO  update  to  be  purged. 

3.  The  Nl  and  NA  control  objects  are  used  to  emulate  the  TELNET  option  negotiation  facility.  The 
facility  is  symmetric,  allowing  either  party  to  open  negotiation  for  a  change  of  mode,  and  every 
negotiation  must  be  accepted  or  rejected  by  the  opposite  party.  The  rules  for  negotiation  for  each 
of  the  option  controls  are  as  stated  in  RFC  854  and  as  given  below: 

a.  Only  open  negotiation  for  a  change  from  the  current  state; 

b.  '     Only  acknowledge  negotiation  for  a  change  from  the  current  state; 

0.        Do  not  send  any  object  updates  with  a  negotiation  outstanding  except  an  update  to  the 
Nl  (or  NA)  control  object  to  acknowledge  negotiation. 

For  full  symmetry,  both  the  Nl  and  NA  control  objects  have  the  same  value  definition  and  consist 
of  4  booleans  with  the  semantics  given  in  Table  8. 


Table  8  ~  NI/NA  CO  value  definition 


BIT 

Option 

Value 

1 

Remote  Echo 

"false"  Echo  is  Local; 
"true"  Echo  is  remote 

2 

Suppress  Go  Ahead 

"false"  GO  Ahead; 

"true"  Suppress  Go  Ahead 

3 

Binary  WACA 

"true"  use  binary  WACA; 

"false"  use  default  or  negotiated 

repertoire  for  HACA  display  object 

4 

Binary  WACI 

"true"  use  binary  WACI; 

"false"  use  default  or  negotiated 

repertoire  for  WACI  display  object 

Booleans  3  and  4  control  the  use  of  the  Transparent  character  set  for  the  D  and  K  display  objects 
respectively.  A  value  of  "Irue"  indicates  the  use  of  the  binary  repertoire;  lalse"  indicates  the  use 
of  the  negotiated  repertoire.  When  a  party  wants  to  change  a  repertoire  assignment,  it  must 
complete  a  successful  TELNET  negotiation  to  change  the  option  control.  Then  the  party  with  the 
access  rights  to  the  display  object  in  question  is  required  to  perform  the  corresponding  secondary 
attribute  modal  update. 

4.  The  TELNET  EC  (erase  character)  command  will  be  mapped  to  a  pointer  relative  (x:  =  x-1)  update 
and  an  erase  current  update.  This  is  the  only  instance  when  liackward  explicit  addressing  is 
permitted. 
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The  TELNET  EL  (erase  line)  command  will  be  mapped  to  an  erase-full-x-an-ay  update  (an  erase 
operation  where  the  extent  is  defined  as  <"8tart-x,"(Yc.Xc-1)>  and  a  pointer  update  to  set  x  =  1. 
This  is  the  only  instance  when  absolute  explicit  addressing  is  permitted. 

5.  The  X  address  of  the  pointer  can  t>e  moved  fonA/ard  only  by  Implicit  pointer  addressing.  Addressing 
of  the  Y  dimension  Is  limited  to  the  next  X-array  update  operation. 

6.  The  VT  next  X-array  update  operation  will  be  sent  in  place  of  the  TELNET  NVT  "CR.LP  sequence. 

7.  While  the  "binary"  repertoire  is  being  used  no  mapping  to  pointer  addressing  or  erase  operations 
will  be  done. 

8.  The  repertoire  designation  "7-bit  ASCII  (GO+CO)"  refers  to  the  repertoire  invoked  by  ISO  2022 
defined  character  set  designating  escape  sequences  <  ESC>  2/8  4/2,  "void,"  <  ESC>  2/1  4/0.  The 
repertoire  designation  "7-bit  ASCII  (GO  only)"  refers  to  the  repertoire  invoked  by  the  ISO  2022 
defined  character  set  designating  escape  sequence  <ESC>  2/8  4/2.  The  designation  "binary" 
refers  to  the  "Virtual  Terminal  Service  Transparent  Set"  registered  in  the  International  Register  under 
ISO  2375  register  value  125  and  invoked  by  the  escape  sequence  <ESC>  2/5  2/15  4/2. 

9.  No  termination  event  list  is  specified  so  that  data  buffering  and  delivery  can  t>e  controlled  according 
to  context.  If  local  echoing  is  enabled,  the  local  newline  or  enter  event  shall  trigger  a  VT-DEUVER 
request.  With  remote  echo  a  timeout  or  buffer  length  may  be  used  to  trigger  a  VT-DELIVER  request. 
This  buffer  length  may  be  1 . 


8.1.6.2        Informative  notes 

1 .  Users  of  this  profile  should  refer  to  the  TELNET  specification  (MIL-STD-1 782)  and  RFCs  854  and  855 
for  semantics  of  the  TELNET  commands.  These  documents  can  be  obtained  by  contacting  SRI 
International,  DDN  Network  Information  Center,  333  Ravenswood  Ave.,  Menio  Park,  CA  94025.  (415) 
859-3695. 

2.  An  update  to  the  GA  control  object  is  equivalent  to  the  TELNET  Go  Ahead  command. 

3.  If  the  "go  ahead"  facility  has  been  negotiated  then  following  a  VT-BREAK,  only  the  association 
acceptor  has  the  right  to  send  data.  In  the  event  of  VT-BREAK  the  echo  control  objects  are 
reinitialized  to  "false,"  meaning  local  echo.  If  remote  echo  is  desired  it  must  be  re-negotiated 
following  VT-BREAK. 

4.  Negotiation  of  TELNET  options  other  than  echo,  transmit  binary,  and  SUPPRESS  GO  AHEAD  is  not 
supported  by  this  profile.  Negotiations  for  these  three  options  can  take  place  at  any  time  during 
a  session. 
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8.1.7      Specific  conformance  requirements 

The  fbUowving  character  sets  are  required: 

The  GO  character  set  for  U.S.  7-bit  ASai  (values  32-126); 
The  fuH  U.S.  7-bit  ASai  (values  0-127). 

The  transparent  character  set.  see  Definitive  Note  8  In  clause  8.1.6.1. 

8.2     Transparent  profile 

OIWVrE-Prone  Transparent-1988  (r1)  * 

8.2.1  Introduction 

This  profle  Is  InterKled  to  provide  a  transparent  mode  of  operation  which  allows  VT-users  to  excfiange  | 
transparently  uninterpreted  sequences  of  characters  but  with  the  added  benefit  of  delivery  control  to  enable 
the  VT-users  to  determine  when  the  character  sequences  are  to  be  delivered.  [ 

This  profle  may  be  used  when  VT-users  wish  to  control  terminals  directly  through  the  use  of  embedded 
control  characters. 

8.2.2  Association  requirements 

8.2.2.1  Functional  units 

No  additional  functional  units  are  required  by  this  profile. 

8.2.2.2  Mode 

This  Is  an  A-mode  prcfiie. 

8.2.3  Profile  body 

Display-objects  *(double  occurrence)*  = 
{ 

{ 

display-object-name  =  D1, 
do-access  =  "WACA", 

! 
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dimensions  =  "one", 

x-dimension  = 
{ 

x-addressing  =  "not-permitted" 

}» 

repertoire-assignment  =  profile-argument-rl 

)■« 

{ 

display-object-name  =  D2, 
do-access  =  "WACI", 

dimensions  =  "one", 

x-dimension  = 

{ 

x-addressing  =  "not-permitted" 

}. 

repertoire-assignment  =  profile-argument-rl 
} 

}. 

type-of-delivery-control  =  "simple-delivery-control." 


8.2.4       Profile  arguments 

n  -  is  optional  and  enables  negotiation  of  a  value  for  the  VTE-parameter  repertoire-assignment  for  the 
two  display  objects  (which  always  have  the  same  value  of  repertoire  assignment  when  the  profile 
is  called).  The  default  value  of  this  argument  is  the  "Virtual  Terminal  Transparent  Set"  registered  in 
the  International  Register  under  ISO  2375  register  value  125,  invoked  by  the  escape  sequence 
<ESC>  2/5  2/15  4/2.  This  argument  is  identified  by  the  identifier  for  repertoire-assignment  for 
display  object  D1. 


8.2.5       Profile  dependent  control  object  information 

This  profile  does  not  reference  any  Control  Objects. 


8.2.6       Profile  notes 

1.  This  profile  Is  intended  primarily  for  applications  requiring  a  simultaneous  two  way  exchange  of 
sequences  of  uninterpreted  characters.  The  semantics  usually  associated  with  the  display  object 
are  not  used;  for  the  purposes  of  this  profile,  the  primary  attributes  of  the  character-box  graphic 
elements  are  actually  octets  which  are  passed  directly  to  the  real  device.  There  is  no  relationship 
between  the  elements  of  the  X-array  and  the  character  boxes  of  the  real  device;  the  secondary 
attributes  of  the  display  object  are  not  utilized.  The  only  operation  on  the  display  object  which  must 
be  supported  is  the  text  operation.  An  alternative  repertoire  may  be  selected. 
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8.2.7       Specific  conformance  requirements 

Support  for  the  default  (transparent)  character  set  is  required.  It  is  strongly  recommended  that  the  profile 
argument  not  be  used. 

8.3      Forms  profile 

OiW  VTE-ProfMe  Fomis-1989  (r1.r2, . . .  r28) 

8.3.1  introduction 

This  S-rTKxie  VTE-profile  is  intended  for  supporting  the  use  of  forms  based,  field  oriented  data  entry 
applications  between  a  terminal  and  a  host  system. 

It  provides  tecllities  for: 

a)  defining  and  using  screen  forms; 

b)  defining  field  validation  and  field  entry  rules; 

c)  controlling  and  validating  field  entry. 

This  VTE-profile  includes  support  of  an  optional  terminal-end  locally  attached  printer. 

8.3.2  Association  requirements 
8.3.2.1        Functional  units 

The  following  VT  functional  units  are  required  for  operation  with  this  profile: 

a)  Enhanced  access-rules; 

b)  Structured  COs; 

c)  Fields; 

d)  Reference  Information  Objects. 

The  following  VT  functional  units  are  optional  for  operation  with  this  profile: 
Urgent  Data 
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8.3.2.2  Mode 

This  Is  an  S-mode  profile. 


8.3.3       Profile  body 

Display-objects  *(single  occurrence)*  = 
{ 

display-object-name  =  A, 
DO-access  =  "WAVAR", 

dimensions  =  "three", 

x-dimension  = 
{ 

x-bound  =  profile-argument-r1 , 

x-addressing  =  "no  constraint", 

x-absolute  =  "yes", 

x-window  =  x-bound 

}. 

y-dimension  = 
{ 

y-bound  =  profile-argument-r2, 

y-addressing  =  "no  constraint", 

y-absolute  =  "yes", 

y-window  =  y-bound 

}. 

z-dimension  = 
{ 

z-bound  =  "unbounded", 

z-addressing  =  "no  constraint", 

z-absolute  =  "no", 

z-window  =  profile-argument-r3 

}. 

erasure-capability  =  "yes", 
repertoire-capability  *(implicitly  defined  by  r4)*, 
repertoire-assignment  =  profiie-argument-r4, 

font-capability  *  (implicitly  defined  by  r5)*, 
font-assignment  =  profile-argument-r5, 
DO-emphasis  =  profile-argument-r6, 

foreground-colour-capability  =  profile-argument-r7, 
foreground-colour-assignment  =  profile-argument-r8, 
background-colour-capability  =  profile-argument-r7, 
background-colour-assignment  =  profile-argument-r9. 
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block-definition-capability  =  'no', 
field-definition-capability  =  'yes', 
max-fields  =  "unbounded', 
max-field-elements  =  profile-argument-r10, 
access-outside-fields  =  profile-argument-rl  1 


Control-objects  = 
{ 

{  *(Field  Definition  CO)^ 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 


=  FD. 

=  vt-b-sco-fdco, 

=  'non-parametric', 

=  'WAVAR'  +  profile-argument-r12, 

=  "normal', 

=  "not-selected" 


}. 


{  *(Field  Entry  Instructions  CO)* 


CO-name 
CO-type-identifier 
CO-structure 
CO-access 
CO-priority 
CO-trigger 
}. 

{  *(Field  Entry  Pilot  CO)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

}. 

{  *(Context  CO)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

}. 


=  El. 

=  "mandatory-feico", 

=  "non-parametric", 

=  "WAVAR"  +  profile-argument-rl  2, 

=  "normal", 

=  "not-selected" 


EP, 

"mandatory-fepco", 

"non-parametric", 

"WAVAR"  +  profile-argument-rl  2, 

"normal", 

"not-selected" 


CC, 

vt-b-sco-cco, 
6, 

"WAVAR", 

"normal", 

"not-selected" 


{  *  (Transmission  Policy  CO)* 
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CO-name  =  TP, 

CO-type-identifier  =  vt-b-sco-tpco, 

CO-structure  =  1, 

co-access  =  "WAVAR"  +  profile-argument-r12, 

CO-priorlty  =  "normal", 

co-trigger  =  "not-selected", 

co-category  =  "boolean", 

co-size  =  4 

}. 

{  *(Multiple  occurrence  of  optional  COs.  All  unspecified  VTE-parameters  of  such  COs 
are  determined  by  their  CO-type-identifier  through  their  registered  definition.  They  may 
include  parameters  specified  to  be  additional  profile  arguments,  which  should  follow  the 
appropriate  CO-type-identifier  argument  value)* 

CO-name  =  profile-argument-r13, 

CO-type-identifier  =  profile-argument-r14 

}. 

{  *(Form  Waiting  Time  CO)* 
CO-name  =  WT, 

CO-type-identifier  =  "waiting-time", 

CO-structure  =1, 
co-access  =  "WAVAR", 

CO-priority  =  "normal", 

CO-trigger  =  "not-selected", 

co-category  =  "integer", 

co-size  =  65535 

}. 

*(The  initial  value  for  WT  is  zero,  implying  that  a  Form  Waiting  Time  is  not  to  be  used.)* 

*(rhe  following  four  COs,  (SA,  UA,  ST,  and  UT),  are  registered  with  the  OIW  registration  authority 
and  are  referenced  by  this  profile.)* 

{  *(As  defined  in  clause  7)* 
CO-name 
CO-type-identifier 
CO-structure 
CO-access 
CO-priority 
CO-trigger 
CO-category 
CO-size 
}. 

{  *(As  defined  in  clause  7)* 


=  SA. 

=  oiw-vt-co-misc-sa, 
=  1. 

=  "WAVAR"  +  profile-argument-r12, 
=  "normal", 
=  "not-selected", 
=  "symbolic", 
=  11 
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}. 


CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trlgger 

CO-category 

co-size 

}. 

{  *(As  defined  in  clause  7)^ 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

co-size 

}. 

{  *(As  defined  in  clause  7)^ 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

CO-size 

} 


UA, 

oiw-vt-co-misc-ua, 
1, 

profile-argument-r1 2, 

"urgent", 

"not-selected", 

"symbolic", 

11 


ST, 

oiw-vt-co-misc-st, 
1. 

"WAVAR"  +  opposite  of  profile-argument-r12, 

"normal", 

"not-selected", 

"integer", 

65535 


UT, 

oiw-vt-co-misc-ut, 
1. 

opposite  of  profile-argument-r12, 

"urgent", 

"not-selected", 

"integer", 

65535 


Device-objects  *(single  or  double  occurrence)*  = 
{ 

{ 

device-name  =  D, 

device-default-CO-access  =  "WAVAR", 
device-default-CO-priority  =  "normal", 
device-default-CO-trigger  =  "not-selected", 
device-default-CO-initial-value  =  1."true", 
device-repertoire-assignment  =  profile-argument-r15, 
device-font-assignment  =  profile-argument-r16, 
device-emphasis  =  profile-argument-r17, 
device-foreground-colour-assignment  =  profile-argument-r1 8, 
device-background-colour-assignment  =  profile-argument-r19. 
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device-minlmum-X-array-length  =  profile-argument-r20, 

device-minlmum-Y-array-length  =  profile-argument-r21 , 

device-control-object  =  FD, 

device-control-object  =  CC, 

device-control-object  =  SA, 

device-control-object  =  UA, 

device-control-object  =  ST, 

device-control-object  =  UT, 

device-control-object  =  WT, 

device-control-object  =  TP, 

device-control-object  =  profile-argument-r22, 

device-display-object  =  A 

}. 

IF  r23  =  "true"  THEN  *(define  printer)* 
{ 

device-name  =  P, 

device-default-CO-access  =  "NSAC", 
device-default-CO-priority  =  "high", 
device-default-CO-trigger  =  "not-selected", 
device-default-CO-initlal-value  =  1. "false", 
device-repertoire-assignment  =  profile-argument-r24, 
device-font-assignment  =  profile-argument-r25, 
device-emphasis  =  profile-argument-r26, 
device-foreground-colour-assignment  =  profile-argument-r27, 
device-background-colour-assignment  =  profile-argument-r28, 
device-minimum-X-array-length  =  profile-argument-r29, 
device-minimum-Y-array-length  =  profile-argument-r30, 
device-control-object  =  FD, 
device-control-object  =  SA, 
device-control-object  =  UA, 
device-control-object  =  profile-argument-r31, 
device-display-object  =  A 
} 


type-of-delivery-control  =  "simple  delivery  control." 
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8.3.4 


FIXED  field  entry  Instruction  definitions  -  non-parametric 


8.3.4.1 


Optional  Field 


Field  entry  is  ofstionai.  Tliis  FEI  is  provided  for  completeness  only,  as  a  field  not  linked  to  one  of  the 
Mandatory  field,  Selectat>le  field  or  Protected  field  FEIs  is  necessarily  optional.  This  FEI  can  never  be 
violated. 


Field  entry  Is  mandatory.  Violation  of  this  FEI  wUI  occur  if  all  array  elements  of  this  field  are  empty  when 
one  of  the  reactions  FER01  (Transmit  updates)  or  FER02  (Relinquish  WAVAR)  is  initiated.  See  also  the 
specification  of  these  reactions  given  below. 


The  field  is  protected  from  field  entry.  Violation  of  this  FEI  will  occur  if  an  attempt  is  made  to  change  the 
primary  or  secondary  attribute  of  any  array  element  of  this  field. 


8.3.4.4        Fill  field 

All  array  elements  k=1  through  k=last  must  have  a  primary  attribute.  Violation  of  this  FEI  will  occur  if  any 
array  element  of  this  field  is  empty  when  one  of  the  reactions  FER01  (Transmit  updates)  or  FER02 
(Relinquish  WAVAR)  is  initiated.  See  also  the  specification  of  these  reactions  given  t)elow. 


8.3.4.5        Echo  received  character 

Allowed  field  entry  characters  are  to  be  echoed  as  received.  This  FEI  is  provided  for  completeness  only, 
as  by  default  characters  will  be  echoed  as  received  unless  the  field  is  linked  to  either  the  Echo  Off  or  the 
Echo  Specified  Character  FEI.  This  FEI  can  never  be  violated. 


8.3.4.6         Echo  off 

Received  field  entry  characters  should  not  be  echoed.  This  FEI  can  never  be  violated. 


8.3.4.7        Ignore  case 

If  this  FEI  is  linked  to  a  field,  upper  and  lower  case  alphabetic  characters  should  be  considered  as  equivalent 
during  the  valkJation  of  field  input  against  all  other  FEIs  linked  to  the  same  field.  This  affects  the 
interpretation  of  the  Allowed  First  Characters,  Allowed  Characters,  Disallowed  Characters  and  Allowed  String 


8.3.4.2 


Mandatory  field 


8.3.4.3 


Protected  field 
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Values  FEIs,  Including  the  precedence  rules  between  the  first  three  of  these  FEIs.  This  FEI  can  never  be 
violated. 


8.3.4.8        Inhibit  logical  rendition  attribute  operation 

No  form  of  logical  attribute  operation,  with  the  exception  of  character  repertoire  switching  as  given  below, 
can  be  performed  on  the  field.  Character  repertoire  changes  are  permitted  if  also  pemiitted  by  Allowed  First 
Characters  or  Allowed  Characters,  see  beiow.  This  FEI  is  intended  to  be  used  when  the  rendition  secondary 
attributes  are  to  be  kept  under  "application"  control.  See.  for  example,  Allowed  First  Characters  for  a  case 
of  reference  to  the  field  modal  values. 


8.3.5       DYNAMIC  field  entry  instruction  definitions  -  parametric 


8.3.5.1        Selectable  field 

The  field  Is  selectable,  i.e.,  field  entry  is  not  permitted  but  information  Is  conveyed  by  ti^e  selection  of  one 
such  field  from  a  number  of  alternatives. 

The  manner  In  which  the  field  that  is  the  current  candidate  for  selection  is  displayed  on  the  real  device  Is 
determined  by  the  optional  "visit"  parameter  of  this  FEi.  This  parameter  specifies  the  secondary  attributes 
to  be  used  for  showing  or  highlighting  this  candidate  to  the  user,  if  it  is  omitted,  an  implementation- 
dependent  default  is  used. 

The  manner  in  which  the  field  that  Is  actually  selected  Is  displayed  on  the  real  device  is  determined  by  the 
optional  "select"  parameter  of  this  FEI.  This  parameter  specifies  the  secondary  attributes  to  be  used  for 
showing  or  highlighting  the  selected  field  to  the  user.  If  it  is  omitted,  an  Implementation-dependent  default 
is  used. 

The  mechanisms  for  moving  among  candidates  and  for  actually  selecting  the  current  candidate  are 
Implementation  defined.  Typically,  a  selectable  field  will  l3e  considered  as  a  candidate  for  selection  when 
the  cursor  is  placed  on  a  character  within  the  selectable  field.  Actual  selection  generates  the  Field  Selected 
FEE.  A  selected  field  is  Indicated  in  a  delivered  update  by  an  addressing  operation  setting  k=l  and  f  and 
z  to  Indicate  the  selected  field.  These  values  will  be  reported  to  the  host  In  the  CCD  if  WAVAR  is 
relinquished  In  reaction  to  this  FEE.  Violation  of  this  FEi  will  occur  if  an  attempt  is  made  to  change  the 
primary  or  secondary  attribute  of  any  array  element  of  this  field. 


8.3.5.2        Echo  specified  character 

Specifies  the  character  which  is  to  be  echoed  to  the  user  in  response  to  each  allowed  character  entered 
into  the  field.  The  secondary  attributes  of  the  echoed  character  may  be  specified.  Any  secondary  attribute 
that  Is  not  given  an  explicit  value  in  the  FEI  takes  a  default  value  in  accordance  with  Definitive  Note  4.  This 
FEI  can  never  be  violated. 
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8.3.5.3        Minimum  entry 

All  array  elements  k= 1  through  k= Minimum  Entry  must  have  a  prinnary  attribute.  If  Minimum  Entry  exceeds 
field  size,  then  all  positions  in  the  field  must  be  filled.  Violation  of  this  FEI  will  occur  if  any  of  the  specified 
array  elements  are  empty  when  one  of  the  reactions  FER01  (Transmit  updates)  or  FER02  (Relinquish 
WAVAR)  is  initiated.  See  also  the  specification  of  these  reactions  given  below.  When  a  field  is  associiated 
with  both  the  Optional  Field  FEI  and  a  Minimum  Entry  FEI,  the  field  is  optional  but  if  entry  is  elected,  the 
number  of  characters  specified  by  the  Minimum  Entry  FEI  must  then  be  entered. 


8.3.5.4        Allowed  first  characters 

Specifies  a  set  of  allowed  characters  for  the  first  character  position  of  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3. 


8.3.5.5        Allowed  characters 

Specifies  a  set  of  allowed  characters  for  all  character  positions  within  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3.  If  Allowed  First 
Characters  and  Allowed  Characters  are  both  specified  for  a  particular  field,  then  the  set  of  Allowed  First 
Characters  applies  to  the  first  character  position  of  the  field  and  the  set  of  Allowed  Characters  applies  to 
the  second  through  last  character  positions  of  the  field. 


8.3.5.6        Disallowed  characters 

Specifies  a  set  of  disallowed  characters  for  all  character  positions  within  a  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3.  If  Allowed  First 
Characters  and  Disallowed  Characters  are  both  specified  for  a  particular  field,  then  the  set  of  Allowed  First 
Characters  applies  to  the  first  character  position  of  the  field  and  the  set  of  Disallowed  Characters  applies 
to  the  second  through  last  character  positions  of  the  field.  When  a  field  is  associated  with  Allowed 
Characters  FEI(s)  and  Disallowed  Characters  FEI(s)  that  have  characters  in  common,  the  common 
characters  are  considered  as  disallowed. 


8.3.5.7        Entry  invoke  character 

Specifies  the  attributes  to  be  used  for  showing  or  highlighting  to  the  user  where  the  next  character  entry  is 
to  be  made.  Both  primary  and  secondary  attributes,  or  secondary  attributes  alone,  may  be  specified  to 
over-rkle  the  corresponding  values  present  in  the  array  element  concerned.  Any  secondary  attribute  that 
is  not  given  an  explicit  value  in  the  FEI  takes  a  default  value  in  accordance  with  Definitive  Note  4.  Fields 
that  are  not  linked  to  an  Entry  Invoke  Character  FEI,  utilize  a  device  dependent  entry  invoke  character 
which  may  or  may  not  be  represented  in  the  character  repertoire  negotiated  for  the  device.  This  FEI  can 
never  t>e  violated. 
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Specifies  the  number  of  seconds  to  wait  for  field  entry  to  complete  after  the  cursor  has  been  positioned 
within  the  field.  Fields  that  are  not  associated  with  a  Waiting  Time  FEI  are  not  subject  to  the  "Fleid  Waitirvg 
Time  Expired"  Field  Entry  Event.  Note  tiiat  an  overall  waiting  time  for  an  entire  form  may  be  set  by  use  of 
the  "waiting-time'  control  object  defined  in  Definitive  Note  1.  This  FEI  can  never  be  violated. 


8.3.5.9        Allowed  string  values 

Specifies  a  list  of  strings  which  identify  valid  field  values.  The  strings  are  specified  as  either  a  discrete 
OCTET  STRING  or  a  range  of  OCTET  STRING,  or  combination  of  both. 

Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and  a  higher  "value"  OCTET  STRING.  The 
"value"  of  an  OCTET  STRING  is  the  integer  value  derived  from  the  collating  sequence  con-esponding  to  the 
repertoire  explicitly  or  implicitly  specified  for  the  OCTET  STRING.  For  example,  the  ISO  646  string  'AB'  hias 
the  integer  value  4142(16)  and  the  string  'ABC  hias  the  value  414243(16). 

When  strings  of  unequal  length  are  compared,  the  smaller  string  is  filled  on  the  right  with  enough  spaces 
to  make  the  strings  of  equal  length.  The  comparison  of  ISO  646  strings  'AB'  ar<j  'ABC  would  be 
accomplished  by  first  converting  the  string  'AB'  to  'AB'  thus  creating  the  value  414220(16)  to  be  compared 
against  the  value  414243(16).  The  value  of  the  space  ciiaracter  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field  modal  attributes.  If  this  repertoire  does  not  contain  a 
space,  then  the  value  20(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note 
3.  A  single  set  of  secondary  attribute  values  may  be  specified  for  each  individual  OCTET  STRING  or  range 
of  OCTET  STRINGS. 


8.3.5.10       Allowed  numeric  values 

Specifies  a  list  of  numeric  strings  which  identify  valid  field  values.  The  strings  are  specified  as  either  a 
'     discrete  OCTET  STRING  or  a  range  of  OCTET  STRING,  or  a  combination  of  both. 

I  Ranges  are  specified  using  a  lower  "Value"  OCTET  STRING  and  a  higher  "Value"  OCTET  STRING.  The 
"value"  of  an  OCTET  STRING  is  the  integer  value  derived  from  the  collating  sequence  con-esponding  to  the 

!  repertoire  explicitly  or  implicitly  specified  for  the  OCTET  STRING.  For  example,  the  ISO  646  string  '12'  has 
the  integer  value  3132(16)  and  the  string  '123'  has  the  integer  value  313233(16). 

When  strings  of  unequal  length  are  compared,  the  smaller  string  is  filled  on  the  left  with  enough  zero 
characters  to  mal<e  the  strings  of  equal  length.  The  comparison  of  ISO  646  strings  '12'  and  '123'  would  be 
accomplished  by  first  converting  the  string  '12'  to  '012'  thus  creating  the  value  303132(16)  to  be  compared 

I  against  the  value  313233(16).  The  value  of  the  zero  character  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field  modal  attributes.  If  this  repertoire  does  not  contain  a 

j     zero,  then  the  value  30(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note 
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3.  A  singto  set  of  secondary  attribute  values  may  be  specified  for  each  individual  OCTET  STRING  or  range 
of  OCTET  STRINGS. 


8.3.6      Mutually  exclusive  FEIs 

Some  FEIs  specify  field  entry  \^idation  rules  that  are  in  conflict  with  the  rules  specified  by  other  FEIs.  For 
example,  a  particular  field  cannot  be  both  "protected"  and  "mandatory."  Such  conflicting  FEIs  cannot  be 
associated  with  the  same  field.  Table  9  defines  Vne  sets  of  conflicting  FEIs. 


* 


: 
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Table  9  -  Sets  of  conflicting  FEIs 


FEI 

Conflicting  FEIs 

Optional  Field 

Mandatory  Field,  Selectable  Field,  Protected  Field 

Mzmdatory  Field 

Optional  Field,  Selectable  Field,  Protected  Field 

Selectable  Field 

All  except  Entry  Invoke  Character  and  Waiting  Time 

cTOteccea  rieiu 

All 

Fill  Field 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Echo  Received 
Character  « 

Selectable  Field,  Protected  Field,  Echo  Off,  Echo 
Specified  Character 

Echo  Off 

Selectable  Field,  Protected  Field,  Echo  Received 
Character,  Echo  Specified  Character 

Ignore  Case 

Selectable  Field,  Protected  Field 

Inhibit  Logical 
Rendition 

Attribute  Operation 

Selectable  Field,  Protected  Field 

Echo  Specified 
Character 

Selectable  Field,  Protected  Field,  Echo  Off,  Echo 
Received  Character 

Minimum  Entry 

Selectable  Field,  Protected  Field 

nil    M»  «A  JX         B  i    mm  ^  ^ 

Allowed  First 
Characters 

Selectable  Field,  Protected  Field,  Allowed  string 
Values,  Allowed  Numeric  Values 

Allowed  Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Disallowed  Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Entry  Invoke  Character 

Protected  Field 

Waiting  Time 

Protected  Field 

Allowed  String  Values 

Selectable  Field,  Protected  Field,  Fill  Field, 
Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters,  Allowed  Numeric  Values 

Allowed  Niimeric  Values 

Selectable  Field,  Protected  Field,  Fill  Field, 
Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters,  Allowed  String  Values 
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8.3.7       FEICO  update  syntax 

In  the  following  syntax,  ASN.1  Value  Assignments  have  been  used  to  attach  value  references  to  values  of 
type  NULL  This  enables  the  values  to  be  referenced  by  these  names  alone,  without  the  need  to  follow  the 
identifier  explicitiy  with  the  value  NUI-L 


FEI  DEFINITIONS  ::=  BEGIN 


FEI  ::=  CHOICE  { 

feiO 

[0] 

IMPLICIT  NULL, 

fei1 

[11 

IMPLICIT  NULL, 

fei2 

[2] 

IMPLICIT  NULL, 

fei3 

[3] 

IMPLICIT  NULL, 

fel4 

[4] 

IMPLICIT  NULL, 

feiS 

[5] 

IMPLICIT  NULL, 

fel6 

[6] 

IMPLICIT  NULL, 

fel7 

[7] 

IMPLICIT  NULL, 

selectableFleld 

[8] 

IMPLICIT  SEQUENCE  { 

visit  [0]  IMPLICIT  SecAttributes  OPTIONAL, 
select  [1]  IMPLICIT  SecAttributes  OPTIONAL 


echoSpecifiedCharacter 

minimumEntries 

allowedFlrstCharacters 

allowedCharacters 

disallowedCharacters 

entrylnvokeCharacter 


[9] 
[10] 

[11] 
[12] 

[13] 
[14] 


[0] 
[1] 

waitingTime 
allowedStringValues 
allowedNunnericValues 


[16] 
[17] 


IMPLICIT 
IMPLICIT 
IMPLICIT 
IMPLICIT 
IMPLICIT 
CHOICE 


}. 

Character, 

INTEGER, 

CharacterValues, 

CharacterValues, 

CharacterValues, 

{ 


IMPLICIT  Character, 
IMPLICIT  SecAttributes  }, 
[15] 


IMPLICIT 
IMPLICIT 
IMPLICIT 


INTEGER, 
CharacterValues, 
CharacterValues  } 


optionalField 

FEI 

felO 

NULL 

mandatoryField 

FEI 

fell 

NULL 

protectedFleld 

FEI 

fel2 

NULL 

fillFleld 

FEI 

fei3 

NULL 

echoReceivedChar 

FEI 

fel4 

NULL 

echoOff 

FEI 

feiS 

NULL 

ignoreCase 

FEI 

fel6 

NULL 

InhibitLogRendAttOp 

FEI 

fei7 

NULL 

Character  ::=  SEQUENCE  { 

primaryValue  [0]      IMPLICIT  PriValue, 
attributes       [1]      IMPLICIT  SecAttributes  OPTIONAL } 
--  When  used  as  one  element  of  a  comparison,  secondary 
-  attributes  are  to  be  compared  only  If  the  attributes 
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element  is  present. 

CharacterValues  ::=  SEQUENCE  OF  SEQUENCE  { 

lowValue  [0]      IMPLICIT  Character. 

hIghValue  [1]      IMPLICIT  PriValue  OPTIONAL } 

-  The  default  for  highValue  is  the  associated 

-  lowValue.  Octet  values  specified  for  highValue 

-  are  constrained  by  the  repertoire  corresponding 

-  to  the  lowValue  value.  The  relationship 

-  [lowValue  <  =  highValue]  must  be  true. 

PriValue  ::=  OCTET  STRING 

-  The  octet  string  comprising  a  value  of  the  PriValue 
--  type  is  constrained  to  the  encoding  of  a  sequence 

-  of  characters  from  the  repertoires  negotiated  for 

-  the  associated  Display  Object.  When  used  in  the 

-  ASN.1  module  FEI,  the  octet  string  is  restricted  to 
■-  the  encoding  of  a  single  character  except  for  its 

-  use  in  allowedStringVaiues  and  allowedNumeric- 

-  Values. 

SecAttributes  ::=  SEQUENCE  { 


repertoire 

[0] 

IMPLICIT 

INTEGER 

OPTIONAL. 

foregroundColour 

[1] 

IMPLICIT 

INTEGER 

OPTIONAL, 

backgroundColour 

[2] 

IMPLICIT 

INTEGER 

OPTIONAL, 

emphasis 

13] 

IMPLICIT 

PrintableString  OPTIONAL, 

font 

[4] 

IMPLICIT 

INTEGER 

OPTIONAL  } 

END  *(FEI  DEFINITIONS)* 

8.3.8       FEICO  "mandatory-feico"  initial  content 

For  each  FEIRxx,  xx  Identifies  the  integer  value  to  be  used  as  "feirList  recordlndex'  in  FDCOUpdate 
operations.  FEICOUpdate  operations  must  use  an  "index"  greater  than  127.  Note  that  the  character 
oriented  FEIRs  for  the  initial  FEICO  utilize  the  default  secondary  attributes,  and  that  the  Selectable  Field  FEI 
uses  implementation-dependent  defaults  for  the  'visit'  and  'select'  secondary  attributes.  The  FEIR  contents 
are  specified  In  terms  of  ASN.1  Value  Notation  appropriate  to  the  FEICO  Update  Syntax  specified  above. 
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Table  10  -  FEICO  "mandatory-feico"  Initial  content 


FEIR 

Value 

FEIROO 

-  not  used  - 

FEIR01 

optionalField 

FEIR02 

mandatoryField 

FEIR03 

selectableField  {  } 

FEIR04 

protectedField 

FEIR05 

fillField 

FEIR06 

echoReceivedCharacter 

FEIR07 

echoOff 

rcinuo 

FEIR09 

inhibitLogRendAttOp 

FEIR10 

allowedCharacters  {{  lowValue  {•41'H}, 
highValue  'SA'H  }}  -  A,B.....Z  - 

FEIR11 

allowedCharacters  {{  lowValue  {'61 'H}, 
highValue  7A'H  }}  -  a,b,...,z  - 

FEIR12 

allowedCharacters  {{  lowValue  {'30'H}, 
highValue 'SS'H  }}- 0,1  9- 

FEIR13 

disallowedCharacters  {{  lowValue  {'41'H}, 
highValue  'SA'H  }}  -  A,B,....Z  - 

FEIR14 

disallowedCharacters  {{  lowValue  {'61'H}, 
highValue  7A'H  }}  -  a,b  z  - 

FEIR15 

disallowedCharacters  {{  lowValue  {'30'H}, 
highValue  '39'H  }}  -  0,1  9- 

FEIR16-FEIR127 

-  These  values  are  reserved  - 

8.3.9       Field  entry  event  definitions 

The  Field  Entry  Events  for  the  mandatory  FEPCO  are  defined  in  the  following  subclauses.  A  parameter  of 
type  "Range"  is  a  sequence  of  integer  pairs,  each  with  an  optional  bitmask.  Each  pair  gives  the  end  points 
of  an  interval  of  integer  values.  An  integer  value  lies  within  the  range  specified  if,  after  applying  the  bitmask 
(if  given)  to  its  binary  form,  it  lies  in  any  of  these  intervals.  The  end  points  of  an  interval  are  included  in  the 
values  of  that  interval. 

It  is  permissible  for  the  ranges  specified  by  the  FEEs  referenced  in  the  entry  control  FEPR-list  of  a  field  to 
overlap.  When  an  event  occurs  which  is  referenced  in  this  way  by  more  than  one  FEPR  linked  to  the  current 
field,  the  FEPR  invoked  is  the  first  FEPR  in  the  FEPR-list  which  both  references  the  event  and  for  which  the 


38 


PART  14  -  VIRTUAL  TERMINAL 

Field  Entry  Conditions  are  satisfied. 


December  1992  (Stable) 


8.3.9.1  FEEOO 
Not  used. 


8.3.9.2        FEE01  logical  keystroke  event  (range) 

This  event  takes  a  range  of  integers  as  a  parameter,  and  occurs  when  a  l^lcai  Keystrol<e  occurs  wUhin 
the  specified  range.  The  Logical  Keystroke  is  either  Initiated  by  the  Logical  Keystrol<e  FER  or  by  the  human 
user,  see  Definitive  Note  8. 


8.3.9.3        FEE02  field  entry  complete 

This  event  is  generated  by  entry  of  a  character  Into  the  last  position  In  a  field,  it  need  not  Imply  that  eM 
character  positions  In  the  field  have  been  entered,  since  these  positions  are  noi  necessarily  written 
sequentially.  Local  cursor  movements,  for  example,  may  be  used  during  local  editing  to  move  the  current 
entry  position  around  the  screen. 


8.3.9.4        FEE03  field  selected 

This  event  is  generated  by  the  selection  of  a  field  that  Is  linked  to  the  Selectable  Field  FEI.  The  means  by 
which  the  cun'ent  candidate  for  selection  Is  actually  selected  Is  Implementation  dependent. 


8.3.9.5        FEE04  field  waiting  time  expired 

The  flekJ  waiting  time  specified  by  the  Waiting  Time  FEI  linked  to  the  curent  fieM  has  been  exceeded. 
Fiekls  not  linked  to  such  an  FEI  are  not  subject  to  this  event. 


8.3.9.6        FEE05  field  entry  instruction  violation 

Some  of  the  defined  FEIs  Imply  Field  Entry  Valuation  by  the  terminal  VT-user.  Flekjs  linked  to  such  FEIs 
are  candkJates  for  erroneous  field  entry.  This  event  Is  generated  when  such  a  vk}iatk)n  occurs,  thus 
enabling  linkage  to  Field  Entry  Reactk>ns  that  may  signal  a  visual  or  audible  Indteatkxi  of  such  a  vtolatkxi, 
or  altemativeiy  may  terminate  local  entry  and  relinquish  WAVAR.  A  yk3lation  FEC  is  avalabie  to  aRow 
different  reactkxis  according  to  which  FEIR  is  violated.  When  the  reaction  Is  to  relinquish  WAVAR,  the  Entry- 
control  Index  and  FEPR  Index  elements  of  the  Context  Control  Object  will  Infonn  the  host  whtoh  FEPR 
caused  the  retum.  If  this  FEPR  has  made  use  of  the  Violation  FEC,  this  FEC  will  kJentIfy  to  the  host  that  ti^e 
vk}iated  FEIR  was  one  of  those  In  the  list  that  forms  the  parameter  value  for  the  FEC.  Unk|ue  ktontWcatkxi 
of  the  FEIR  Is  obtained  If  this  list  contains  only  one  FEIR.  The  host  can  then  take  whatever  actkxi  Is 
appropriate  to  the  FEIR  or  FEIRs  so  klentlfied. 
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8.3.10     Field  entry  condition  definitions 

The  elementary  Field  Entry  Conditions  for  the  niandatory  FEPCO  are  defined  below.  Composite  conditions 
can  be  built  by  use  of  the  specified  parameters,  and  an  individual  FEPR  can  include  multiple  conditions  in 
accordance  with  20.3.5.2  of  ISO  9040. 

A  parameter  of  type  Action  is  specified  either  as  an  explicit  integer  value  or  as  the  current  keystroke,  see 
Definitive  Note  8.  Such  a  parameter  evaluates  to  an  integer  of  the  type  STCO.Key  defined  in  clause  7.3.7. 
That  clause  also  defines  names  of  logical  keystrokes  associated  with  these  integers.  The  local  actions 
associated  with  such  values  are  defined  in  Definitive  Note  9. 


8.3.10.1  FECOO 

Not  used. 


8.3.10.2       FEC01  no  previous  field 

The  current  field  has  no  currently  defined  previous  field,  in  the  sense  of  20.3.3.4  of  ISO  9040. 


8.3.10.3       FEC02  no  next  field 

The  current  field  has  no  currently  defined  next  field,  in  the  sense  of  20.3.3.4  of  ISO  9040. 


8.3.1 0.4       FEC03  Start  of  field 

The  current  location  for  the  next  character  entry  is  at  the  first  location  in  the  current  field. 


8.3.10.5       FEC04  end  of  field 

The  current  location  for  the  next  character  entry  is  at  the  last  location  in  the  current  field. 


8.3.10.6       FEC05  at  tab  stop 

The  current  location  for  the  next  character  entry  is  at  a  tabulation  stop  defined  by  the  optional  Horizontal 
Tabulation  CO  {ewos-vt-co-misc-ht}  registered  with  the  EWOS  Registration  Authority.  If  this  CO  is  not 
present  in  the  VTE,  this  condition  is  deemed  to  be  always  satisfied. 
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8.3.10.7       FEC06  at  characters  (set  of  character  values) 

The  current  location  for  the  next  character  entry  is  at  an  array  element  whose  current  value  Is  one  of  the 
specified  characters.  The  set  of  characters  is  specified  and  interpreted  in  accordance  with  Definitive  Note 
3. 


8.3.10.8       FEC07  exits  field  (action) 

The  local  action  designated  by  the  paranieter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  field. 


8.3.10.9       FECOB  exits  forward  path  (action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  fon/vard  navigation  path  starting  at  the  current  field. 


8.3.10.10     FEC09  exits  backward  path  (action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  backward  navigation  path  starting  at  the  current  field. 


8.3.1 0.1 1      FECI  0  exits  x-array  (action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  x-array. 


8.3.10.12      FEC11  exits  y-array  (action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  y-array. 


8.3.10.13  FECI  2  not  FEC  (FEC) 

This  condition  is  satisfied  precisely  when  the  FEC  given  as  its  parameter  is  not  satisfied. 

8.3.1 0.1 4  FECI  3  and  FECs  (set  of  FEC) 

This  condition  is  satisfied  when  each  of  the  conditions  in  the  set  comprising  its  parameter  is  satisfied. 
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8.3.1 0.1 5      FECI  4  or  FECs  (set  of  FEC) 

This  condition  is  satisfied  when  at  least  one  of  the  conditions  in  the  set  comprising  its  parameter  is  satisfied. 


8.3.1 0.1 6      FECI  5  violation  (set  of  FEIR  identifiers) 

This  condition  is  provided  for  use  in  conjunction  with  the  Field  Entry  Instruction  Violation  FEE.  Its  parameter 
is  an  FEIR-list  specified  as  a  set  of  FEIR  identifiers.  Each  identifier  is  a  pair  <FEICO-name,  index>  where 
index  is  an  integer  addressing  a  record  in  the  FEICO  whose  name  is  specified.  This  FEC  is  satisfied  if  the 
FEIR  whose  violation  generated  this  event  is  one  of  the  FEIRs  in  this  FEIR-list.  If  it  is  used  in  conjunction 
with  any  other  FEE  then  this  condition  is  true. 


8.3.10.17      FECI  6  unconditional 

This  condition  is  always  true.  It  is  given  for  completeness  only,  and  has  the  same  effect  as  an  empty  set 
of  conditions  In  an  FEPR. 


8.3.11      Field  entry  reaction  definitions 

The  Field  Entry  Reactions  for  the  mandatory  FEPCO  are  defined  below.  The  significance  of  a  parameter 
of  type  "Action"  is  as  described  for  Field  Entry  Conditions.  A  parameter  of  type  "ResetAttribute"  may  take 
either  of  the  two  values  "reset"  and  "noReset."  Such  a  parameter  controls  the  effect  of  an  erase  operation 
on  the  secondary  attributes  of  the  erased  elements,  corresponding  to  the  values  "yes"  and  "no"  for  the  reset- 
attribute  parameter  of  a  LOGICAL-ERASE  operation  as  defined  in  19.2.3.5  of  ISO  9040. 


8.3.11.1  FEROO 

Not  used. 


8.3.1 1 .2       FER01  transmit  updates 

The  host  copy  of  the  CCA  is  updated  to  correspond  to  the  terminal  copy  by  the  transmission  of  all 
undelivered  update  operations.  The  operations  required  to  update  field  contents  are  controlled  by  the  T- 
policy  component  of  the  Field  Definition  Record  for  the  fields  concerned.  However,  if  this  FER  generates  i 
an  FEI  violation  in  accordance  with  the  specifications  of  the  FEICO(s)  present  in  the  VTE,  and  if  the  current  I 
field  is  also  linl<ed  to  an  FEPR  with  event  FEE05  (FEI  violation)  and  satisfied  conditions,  then  this  FER  is  not 
performed  and  that  FEPR  is  activated;  the  original  FEPR  is  abandoned. 
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8.3.1 1 .3       FER02  relinquish  WAVAR 

The  action  described  under  Transmit  Updates  Is  performed,  followed  by  retum  of  the  WAVAR  access  right 
to  the  host.  However,  If  this  FER  generates  an  FEI  violation  In  accordance  with  the  specifications  of  the 
FEICO(s)  present  In  the  VTE,  and  If  the  current  field  Is  also  linked  to  an  FEPR  with  event  FEE05  (FEI 
violation)  and  satisfied  conditions,  then  this  FER  is  not  performed  and  that  FEPR  Is  activated;  the  original 
FEPR  is  abandoned. 


8.3.1 1 .4       FER03  erase  field  right  (reset  attribute) 

The  primary  attribute  value  is  cancelled  for  all  elements  of  the  current  field  from  the  current  character  entry 
location  to  the  end  of  the  field.  The  effect  on  the  secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  described  atx>ve. 


8.3.11.5       FER04  erase  path  right  (reset  attribute) 

The  primary  attribute  value  Is  cancelled  for  all  elements  of  all  unprotected  fields  In  the  forward  navigation 
path  containing  the  current  field,  from  the  current  character  entry  location  onwards.  Note  that  the  forward 
navigation  path  may  not  terminate,  as  its  definition  in  20.3.3.4  of  ISO  9040  does  not  prohibit  looping.  When 
a  loop  is  entered  during  this  operation,  the  operation  terminates  when  all  elements  of  the  entered  loop  have 
been  erased.  The  effect  of  this  operation  on  the  secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  descrit>ed  above. 


8.3.11.6       FER05  local  action  (action) 

That  local  action  is  performed  which  is  designated  by  the  given  parameter  value.  The  specification  of  these 
local  actions  is  given  in  Definitive  Note  9. 


8.3.11.7       FER06  logical  keystroke  (action) 

Initiate  the  FEPR  processing  which  would  occur  if  the  given  keystroke  had  occun-ed.  This  may  itself  cause 
the  Logical  Keystroke  FER  and  hence  recursive  processings  of  FERs.  Processing  of  cun-ent  FERs  Is 
suspended  until  this  recursive  processing  is  complete.  During  recursive  processing,  the  current  keystroke 
is  taken  as  the  argument  to  this  FER.  When  the  recursive  processing  is  complete,  the  previous  keystroke 
is  restored  and  processing  of  current  FERs  is  resumed. 


8.3.1 1 .8       FER07  update  ST  CO  (action) 

The  integer  value  corresponding  to  the  given  parameter  Is  written  to  the  Sequenced  Temiinal  CO.  This  FER 
will  usually  be  followed  by  a  Transmit  Updates  or  Relinquish  WAVAR  FER  to  communicate  the  update  to  the 
application. 
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8.3.11.9       FER08  update  UT  CO  (action) 

The  integer  value  corresponding  to  the  given  parameter  is  written  to  the  Unsequenced  Terminal  CO.  This 
update  wm  be  communicated  to  the  application  immediately. 


8.3.11.10     FER09  execute  RIO  record  (RIO  record  Id) 

An  EXECUTE-RECORD  operation  is  performed  on  the  RIO  record  specified  in  the  parameter,  in  accordance 
with  22.4.1  of  ISO  9040. 


8.3.1 1 .1 1      FER01 0  call  RIO  record  (RIO  record  Id) 

A  CALL-RECORD  operation  is  performed  on  the  RiO  record  specified  in  the  parameter,  In  accordance  with 
22.4.2  of  ISO  9040. 


8.3.11.12      PERU  Visual  Indication 

Present  a  visual  indication  in  response  to  Field  Entry  Instruction  violations. 


8.3.1 1.13     FER1 2  audible  indication 

Present  an  audible  indication  in  response  to  Field  Entry  instruction  violations. 


8.3.11.14     FER1 3  conditional  branch 

(if:  FEC,  then:  Optional  sequence  of  FER,  else:  Optional  sequence  of  FER) 

if  the  condition  given  by  the  "IT  parameter  is  satisfied  then  perform  the  sequence  of  reactions  given  by  the 
"then"  parameter,  else  perform  the  sequence  of  reactions  given  by  the  "else"  parameter. 


8.3.1 1 .1 5     FER1 4  prevent  further  entry 

it  is  recommerxJed  that  if  a  type-ahead  buffer  is  in  use  by  the  local  user  interface,  this  reaction  should 
prevent  further  entry  into  the  buffer.  Attempted  entry  may  then  sound  an  alarm  or  be  signalled  by  some 
other  local  means,  but  is  not  an  FEI  violation,  if  the  WAVAR  access  right  is  relinquished  without  this  reaction 
being  Invoked,  the  buffer  may  continue  to  accept  entries.  Entry  into  the  buffer  is  resumed  when  WAVAR 
Is  next  retumed  to  the  terminal,  it  is  not  a  violation  of  this  profile  specification  if  the  terminal  VT-user  does 
not  t)ehave  In  the  intended  manner. 
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8.3.1 1 .1 6     FER1 5  write  disallowed  character 

The  most  recent  disallowed  character  Is  written  as  if  it  were  not  disallowed.  If  there  has  t>een  no  disallowed 
character,  the  effect  is  null.  This  FER  is  used  when  it  is  desired  to  trap  the  entry  of  a  particular  character, 
not  to  forbid  it  but  instead  to  generate  some  other  reactions  In  addition  to  the  character  entry. 


8.3.11.17     FER1 6  write  String  (Character  string) 

The  character  string  given  as  a  parameter  is  written  as  LOGICAL  TEXT  to  the  current  entry  location  without 
regard  to  FEICO  control.  If  the  end  of  the  field  Is  reached  before  the  string  has  been  written  In  its  entirety, 
the  reaction  is  terminated  prematurely. 


8.3.12      Field  entry  pilot  update  syntax 

in  the  following  syntax,  ASN.1  Value  Assignments  have  been  used  to  attach  value  references  to  values  of 
type  NULL  This  enables  the  values  to  be  referenced  by  these  names  alone,  without  the  need  to  follow  the 
Identifier  explicitly  with  the  value  NULL 


FEPR 


DEFINITIONS  ::=  BEGIN 


FEE: 


=  CHOICE  { 
loglcalKeystroke 


[11 
[2] 
[31 
[41 
[51 


IMPLICIT  Range, 
IMPLICIT  NULL, 
IMPLICIT  NULL, 
IMPLICIT  NULL, 
IMPLICIT  NULL  } 


fee02 
feeOS 
fee04 
feeOS 


fieldEntryComplete  FEE 
fieldSelected  FEE 
fieldWaitTlmeExpired  FEE 
feiVlolatlon  FEE 


fee02  NULL 
fee03  NULL 
fee04  NULL 
feeOS  NULL 
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FEC::=  CHOICE  { 
fecOl 
1eo02 
fec03 
1ec04 
feoOS 
atChar 
exitsField 
exitsFofwardPath 
exitsBackwardPath 
exitsXarray 
exitsYarray 
not 
and 
or 

violation 


fec16 


[I]  iMPLiCITNULL, 
[2]  iMPUCITNUU-. 
[3]  IMPUCITNUU^ 
[4]  iMPUCITNUU-, 
[5]  IMPUCiTNULL, 

[6]  iMPUCIT  FEi.CharacterValues, 
[7]  Action, 
[8]  Action, 
[9]  Action, 
[10]  Action, 

[II]  Action, 
[12]  FEC, 

[13]  IMPUCiT  SET  OF  FEC, 
[14]  iMPUCIT  SET  OF  FEC, 
[15]  IMPUCIT  SET  OF  SEQUENCE 
{ feicoName  PrintableString, 
recordlndex   INTEGER  }, 
[16]  IMPUCIT  NULL  } 


noPreviousFleld 

noNextReid 

startReid 

endReld 

atTab 

unconditional 


FEC 
FEC 
FEC 
FEC 
FEC 
FEC 


fecOl 
fec02 
fec03 
fec04 
fecOS 
fec16 


NULL 
NULL 
NULL 
NULL 
NULL 
NULL 


46 


PART  14  -  VIRTUAL  TERMINAL 


December  1992 


FER  ::=  CHOICE  { 


fer01 

[1]  IMPLICIT  NULL, 

fer02 

[2]  IMPLICIT  NULL, 

eraseFieldRight 

[3]  IMPLICIT  ResetAttrlbute, 

erasePathRight 

[4]  IMPLICIT  ResetAttrlbute, 

local 

[5]  Action, 

loglcalKeystroke 

[6]  Action, 

updateSTCO 

[7]  Action, 

updateUTCO 

[8]  Action, 

executeRIO 

[9]  IMPLICIT  RIORecordID, 

callRIO 

[10]  IMPLICIT  RIORecordID, 

fer11 

[11]  IMPLICIT  NULL, 

fen  2 

[12]  IMPLICIT  NULL, 

branch 

[13]  IMPLICIT  SEQUENCE  { 

if        [1]  FEC, 

then    [2]  IMPLICIT  SEQUENCE  OF  FER  OPTIONAL, 
else     [3]  IMPLICIT  SEQUENCE  OF  FER  OPTIONAL  }, 
fer14  [14]  IMPLICIT  NULL, 

fer15  [15]  IMPLICIT  NULL, 

writeString  [16]  IMPLICIT  SEQUENCE  OF 

FEI. Character 

-  The  string  written  by  this  FER  is  the 

-  concatenation  of  the  strings  specified  by 

-  the  individual  FEI. Character  values.  -  } 


transmitUpdates 

FER  : 

:=  ferOI  NULL 

relinquishWAVAR 

FER  : 

:=  fer02  NULL 

visuallndication 

FER  : 

:=  ferll  NULL 

audiblelndication 

FER  : 

:=  fer12  NULL 

preventFurtherEntry 

FER  : 

:=  fer14  NULL 

writeDisallowedChar 

FER  : 

:=  fer15  NULL 

RIORecordID  ::=  SEQUENCE  { 

rioName  [1]  IMPLICIT  PrintableString  OPTIONAL, 

-  optional  if  there  is  only  1  RIO  in  the  VTE 
recordID  [2]  IMPLICIT  PrintableString  } 


Range  ::=  SEQUENCE  OF  SEQUENCE  { 

[1]  IMPLICIT  STCO.Key, 
[2]  IMPLICIT  STCO.Key  OPTIONAL, 
mask  [3]  IMPLICIT  BIT  STRING  OPTIONAL  } 

-  The  first  two  values  of  each  trio  represent  an 

-  interval  of  logical  keystroke  values.  The  second 

-  value  in  each  pair  shall  not  be  smaller  than  the 
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-  first  value.  If  the  second  value  Is  omitted,  the 

-  interval  contains  only  the  specified  first  value. 

-  if  the  optional  masl<  is  given,  then  the  value  being 

-  tested  is  bitwise  logically  ANDed  with  the  mask 

-  before  being  compared  with  the  end  points  of  the 

-  interval. 


ResetAttribute  BOOLEAN 

reset  ResetAttribute  ::=  TRUE 

noReset  ResetAttribute  ::=  FALSE 

Action  ::=  CHOICE  { 

[1]  IMPLICIT  STCO.Key, 
current         [2]  IMPLICIT  NULL  } 

currentKeystroke  Action  ::=  current  NULL 

The  ASN.1  module  STCO  is  defined  in  the  specification  of 
--  the  Sequenced  Terminal  CO  in  clause  7.3.  STCO.Key  is 

-  an  integer  type  with  a  named  number  list,  each  named 

-  number  representing  a  specific  logical  keystroke  as 
--  defined  for  that  CO. 


END  *(FEPR  DEFINITIONS)* 


FEPCO  "mar)datory-fepco"  Initial  Content 

For  each  FEPRxx,  xx  identifies  the  integer  value  to  be  used  as  leprList  recordlndex"  in  FDCOUpdate 
operations.  FEPCOUpdate  operations  must  use  an  "index"  greater  than  127.  The  FEPR  contents  are 
specified  in  terms  of  ASN.1  Value  Notation  appropriate  to  the  FEPCO  Update  Syntax  specified  above.  Note 
that  "shiftTab"  is  a  named  integer  of  type  STCO.Key.  The  local  action  it  designates  is  defined  in  Definitive 
Note  9  to  be  movement  of  the  current  character  entry  position  to  the  first  location  of  the  next  field  in  the 
forward  navigation  path. 
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Table  11  -  FEPCP  'mandatory-fepco"  Initial  content 


FEPK  No 


CoMponent 


ASH.l  Deacrlptlon 


FEPROO 
FEPROl 


FEPR02 


FEPR03 


FEPR04 


FEPR05 


FEPR06 


FEPR07 


FEPR08 


FEPR09- 
FEPR127 


FEE 
FEC 
FEROl 
FER02 

FEE 
FEC 
FER 

FEE 
FEC 
FER 

FEE 
FEC 
FER 

FEE 
FEC 
FER 

FEE 
FEC 
FER 

FEE 

FEC 
FER 

FEE 
FEC 
FER 


— Not  used — 

logicalKeystroke  {  {  0,  65535  )  ) 
uncond  i  t  i  ona 1 

updateSTCO  cur rent Keystroke 
r el i  nqu  i  shWAVAR 

£  i  eldEnt  ryComplet e 

noNextField 

rel i nqu i ShWAVAR 

fi eldEnt ryComplete 
not  noNextField 
local  shiftTab 

f ieldSelected 
unconditional 
relinquishHAVAR 

fieldWaitTimeExpired 

noNextField 

r e 1 i nqu i s h WAVAR 

fieldWaitTimeExpired 
not  noNextField 
local  shiftTab 

f eiViolation 

unconditional 

visuallndication 

feiViolation 

unconditional 

audiblelndication 

~  Reserved  — 


8.3.13      Profile  arguments 

n  -    is  optionaS  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  x-bound.  It  takes  an 
integer  value  greater  than  zero.  Default  Is  80. 

r2  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  y-bound.  It  takes  an 
integer  value  greater  than  zero.  Default  is  24. 

r3  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  z-window.  It  takes  an 
integer  value  greater  than  zero.  Default  is  1 . 

r4  -    is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  repertoire-assignment.     The  value  for  the  VTE-parameter 
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repertoire-capability  is  implied  by  tlie  number  of  occurrences  of  this  profile  argument.  Deteult  is  a 
single  occurrence  with  the  value  {value  iso2022  {'2842'H}}  of  ASN.l  type 
CDS.RepertoireAsslgnnrtent  as  defined  in  ISO  9041,  designating  the  GL  set  ISO  2375  Reg.  No.  6 
(ASCII). 

rS  -  Is  optional,  may  occur  a  number  of  times  In  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  font-assignment.  The  font-assignment-type  component  of  a  font- 
assignment  value  is  an  ASN.l  OBJECT  IDENTIFIER  that  designates  a  registered  syntax  and 
semantics  for  the  font-assignment-value  component.  The  value  for  the  VTE-parameter  font-capability 
is  implied  by  the  number  of  occurrences  of  this  profile  argument.  If  there  are  no  explicit 
occun'ences  of  this  profile  argument  then  the  font-capability  and  font-assignment  VTE-parameters 
take  the  deteuit  values  specified  in  ISO  9040. 

r6  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  DO-emphasls.  The  syntax  and  semantics  for  this  VTE-parameter  are 
specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified  in  B.I  7.4  of  ISO  9040.  The 
default  value  for  the  occurrence  corresponding  to  each  unspecified  subattribute  is  the  ASN.l 
PrintableString  of  length  1  specifying  the  explicit  modal  default  value  for  tiiat  subattribute. 

r7  -  Is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameters 
foreground-colour-capability  and  background-colour-capability.  Default  Is  8.  This  argument  is 
klentifled  by  the  kientifier  for  the  VTE-parameter  foreground-colour-capability  for  display  object  A. 

r8  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  foreground-colour-assignment.  The  default  values  for  unspecified 
occurrences  of  this  profile  argument  are  the  corresponding  values  from  the  ordered  list  {"white," 
"black,"  "red,"  "cyan,"  "blue,"  "yellow,"  "green,"  "magenta"}.  There  are  no  default  values  if  the  value 
of  the  VTE-parameter  foreground-colour-capability  exceeds  8. 

r9  -  Is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provkJes  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  background-colour-assignment.  The  default  values  for  unspecified 
occurrences  of  this  profile  argument  are  the  corresponding  values  from  the  ordered  list  {"black," 
"white,"  "cyan,"  "red,"  "yellow,"  "blue,"  "magenta,"  "green"}.  There  are  no  default  values  If  the  value 
of  the  VTE-parameter  background-colour-capability  exceeds  8. 

no  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  max-field-elements. 
Default  Is  1. 

r1 1  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  access-outskie-fields. 
Default  Is  "not  allowed." 

r12  -  Is  mandatory  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  CO-access  for  the 
Field  Definition,  Field  Entry  Instruction,  Field  Entry  Pilot,  Transmission  Policy,  Sequenced 
Application,  Unsequenced  Application,  Sequenced  Terminal,  and  Unsequenced  Terminal  control 
objects.  If  the  VT-association  initiator  is  the  terminal  VT-user,  it  takes  the  value  "WACA,"  othenA/ise 
It  takes  the  value  "WACI."  This  argument  is  kJentified  by  the  identifier  for  CO-access  for  control 
object  UA. 
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r13  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  a  value  for  the  VTE- 
parameter  CO-name  for  optional  registered  COs.  By  default  no  optional  COs  are  Invoked. 

r14  -  Is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  a  value  for  the  VTE- 
parameter  CO-type-identifier  for  optional  registered  COs.  The  particular  generic  type  concerned  is 
determined  from  the  CO-type-identifier  by  the  register  entry.  The  value  vt-b-sco-nullrto  selects  an 
empty  RIO.  An  occurrence  of  the  previous  argument  specifies  the  presence  of  an  optior>ai  CO  in 
the  VTE-profile.  An  occurrence  of  this  argument  is  required  for  every  occurrence  of  the  previous 
argument.  By  default  no  optional  COs  are  invoked. 

r15  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-repertoire-assignment  for  the  main  device.  Default  is  'null' 
for  each  unspecified  occurrence. 

r16  -  Is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-font-assignment  for  the  main  device.  Default  is  'null'  for  each 
unspecified  occurrence. 

r17  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-emphasis  for  the  main  device.  The  syntax  and  semanttes  for 
this  VTE-parameter  are  specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified  in 
8.1 7.4  of  ISO  9040.  Default  is  "null"  for  each  unspecified  occurrence. 

r18  -  Is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiatkMi  of  a 
value(s)  for  the  VTE-parameter  device-foreground-colour-asslgnment  for  the  main  device.  Default 
Is  "null"  for  each  unspecified  occurrence. 

r19  -  Is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-background-coiour-assignment  for  the  main  device.  Default 
Is  "null"  for  each  unspecified  occurrence. 

r20  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
devlce-mlnimum-X-array-length  for  the  main  device.  It  takes  an  integer  value  greater  than  zero. 

Default  Is  the  value  of  x-bound  for  the  display  object. 

r21  -  Is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
devlce-minlmum-Y-array-8ength  for  the  main  device.  It  takes  an  integer  value  greater  than  zero. 

Default  Is  the  value  of  y-bound  for  the  display  object. 

r22  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  additional  values  for 
the  VTE-parameter  device-control-ob|ect  for  the  main  device.  By  default  there  are  no  addltk)nal 
values. 

r23  -  Is  a  special  profile  argument  Wentlfied  by  the  special-proflie-arg-klent  "Pp-1.'  It  is  optkxial  and 
provides  for  the  negotiation  of  a  printer  device.  Default  is  false." 

r24  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiatton  of  a 
value(s)  for  the  VTE-parameter  device-repertoire-assignment  for  the  printer  device.  Default  Is  'null' 
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for  each  unspecified  occurrence. 

r25  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-font-assignment  for  the  printer  device.  Default  is  "null"  for  each 
unspecified  occurrence. 

r26  -  is  optional,  may  occur  a  numt>er  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-emphasis  for  the  printer  device.  The  syntax  and  semantics 
for  this  VTE-parameter  are  specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified 
in  B.I 7.4  of  ISO  9040.  Default  is  'null'  for  each  unspecified  occurrence. 

r27  -  is  optional,  may  occur  a  numt>er  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-foreground-colour-assignment  for  the  printer  device.  Default 
is  'biack*  for  each  unspecified  occurrence. 

r28  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-background-colour-assignment  for  the  printer  device.  Default 
is  'white'  for  each  unspecified  occurrence. 

r29  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-X-array-length  for  the  printer  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  x-bound  for  the  display  object. 

r30  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-Y-array-length  for  the  printer  device,  it  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  y-bound  for  the  display  object. 

r31  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  additional  values  for 
the  VTE-parameter  device-controi-object  for  the  printer  device.  By  default  there  are  no  additional 
values. 


8.3.14     Profile  dependent  control  objects 

This  profile  uses  the  OIW  registered  Control  Objects  SA,  UA,  ST  and  UT.  The  profile  defined  values  are 
specified  in  the  body  of  this  profile.  The  CO  specifications  require  the  usage  of  each  CO  to  be  specified 
In  the  profile.  This  is  as  follows. 


8.3.14.1       Sequenced  Application  CO 

This  Control  Object  is  defined  in  7.1.  It  has  CO-category  'symbolic."  Update  of  this  CO  with  the  value 
"audlble_alarm'  sounds  an  audible  alarm  in  the  terminal.  Update  with  the  value  'visual_alarm''  generates  a 
visual  indication  of  a  signal  from  the  application.  Ail  other  values  have  no  effect. 
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8.3.14.2       Unsequenced  Application  CO 

This  Control  Object  is  defined  In  7.2.  It  has  CO-category  "symbolic."  Update  of  this  CO  with  the  value 
"audlble_alarm"  sounds  an  audible  alami  in  the  temnlnal.  Update  with  the  value  Visuai  alann"  generates  a 
visual  Indication  of  a  signal  from  the  application.  All  other  values  have  no  effect. 


8.3.14.3       Sequenced  Terminal  CO 

This  Control  Object  Is  defined  In  7.3.  It  has  CO-category  "integer."  It  is  updated  by  the  Update  ST  CO  FER. 
and  may  be  used  to  communicate  uninterpreted  keystrokes  to  the  application. 


8.3.14.4       Unsequenced  Terminal  CO 

This  Control  Object  is  defined  in  7.4.  It  has  CO-category  "integer."  It  is  updated  by  the  Update  UT  CO  FER 
and  Is  used  to  communicate  uninterpreted  keystrokes  to  the  application  urgently. 


8.3.15     Profile  notes 


8.3.15.1       Definitive  notes 

1 .  The  WT  control  object  provides  a  mechanism  for  the  application  VT-user  to  specify  a  time  in  which 
all  the  fields  of  a  form  must  be  completed.  The  terminal  VT-user  starts  the  timer  at  the  time  when 
it  receives  WAVAR.  If  the  timer  expires,  further  entry  by  the  device  is  stopped,  all  undelivered 
updates  are  transmitted,  and  WAVAR  is  relinquished.  The  undelivered  updates  are  transmitted 
followed  by  an  update  to  this  control  object.  The  WT  update  is  made  using  the  current  value  of  the 
WT  control  object.  The  device-control-object  VTE-parameter  is  used  to  link  this  CO  to  the  input 
device  that  it  controls.  The  data  element  of  this  CO  specifies  the  waiting  time  in  seconds.  A  zero 
value  signifies  that  a  Form  Waiting  Time  is  not  to  be  used.  The  initial  value  of  this  data  element  is 
zero. 

2.  If  there  are  two  or  more  Character-oriented  FEIs  of  the  same  type  associated  with  the  same  field, 
they  are  equivalent  to  a  single  FEI  of  that  type  whose  parameter  is  the  concatenation  of  thte 
Individual  parameter  values. 

3.  The  following  parameteric  FEIs  and  FECs  defined  in  clause  8.3.4  test  equality  of  characters: 

Allowed  First  Characters  FEI 
Allowed  Characters  FEI 
Disallowed  Characters  FEI 
Allowed  String  Values  FEI 
Allowed  Numeric  Values  FEI 
At  Characters  FEC 
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The  characters  for  each  such  FEI  or  FEC  are  specified  by  a  parameter  that  includes  an  optional  set 
of  secondary  attributes,  if  this  set  is  included,  the  test  is  on  both  prinnary  and  secondary  attributes; 
otherwise  it  is  on  primary  attributes  only.  If  the  test  is  on  primary  attributes  only,  then  characters 
which  pass  the  test  are  allowed,  disallowed  or  accepted,  as  appropriate,  irrespective  of  the  values 
of  their  secondary  attributes.  The  set  of  secondary  attributes  need  not  specify  an  explicit  value  for 
every  secondary  attribute;  in  particular  the  empty  set  is  permissible.  Default  values  are  used  for 
unspecified  secondary  attributes.  These  are  determined  in  accordance  with  Definitive  Note  4. 

4.  The  parameter  values  for  a  number  of  FEIs,  FECs  and  FERs  require  default  values  to  be  used  for 
secondary  attributes  when  such  values  are  not  specified  explicitly  by  the  parameter.  The  first  choice 
default  for  each  secondary  attribute  value  is  the  field  modal  attribute  value  at  the  time  that  the  FEI, 
FEC  or  FER  is  accessed.  A  first  choice  default  value  of  "null"  is  resolved  as  specified  In  19.2.3.1  of 
ISO  9040  for  the  LOGICAL-TEXT  update  operation. 

5.  When  the  Cliaracter  oriented  FEIs  associated  with  a  particular  field  have  ciiaracters  in  common,  the 
precedence  algorithm  given  below  is  used. 

The  Allowed  First  Characters  FEI  takes  precedence  over  the  Allowed  Characters  and  Disallowed 
Characters  FEIs  for  field  character  position  l<=1.The  Disallowed  Characters  FEI  takes  precedence 
over  the  Allowed  Characters  FEI  for  all  field  character  positions. 

The  following  example  illustrates  the  conflict  resolution  algorithm.  When  a  particular  field  is  linked 
to  the  following  three  Character  oriented  FEIs: 

Allowed  First  Characters      =  a 
Allowed  Characters  =  a,b 

Disallowed  Characters        =  a 

the  field  must  be  entered  with  the  letter  "a"  in  the  first  character  position  of  the  field.  The  remaining 
character  positions  in  the  field  are  limited  to  containing  the  letter  "b."  Therefore  field  entry  would 
be  limited  to  a  form  such  as  "abbbb.  ..." 

6.  The  following  syntax  and  semantics  is  mandatory  for  the  emphasis  and  device-emphasis  VTE- 
parameters.  The  scheme  of  B.I 7.3  of  ISO  9040  is  to  be  adopted  except  that  the  maximum  length 
for  an  ASN.l  PrintableString  used  as  an  emphasis  value  is  increased  from  6  characters  to  8 
characters.  Values  "B"  (Boxed)  and  "C"  (Encircled)  are  deleted  from  subattribute  "b."  Two  further 
subattributes  are  added,  denoted  by  "g"  and  "h."  The  table  of  allowed  character  values.  ISO  6429 
SET  GRAPHIC  RENDITION  parameter  values  and  associated  semantics  given  in  B.I  7.3  of  ISO  9040 
is  augmented  by  the  addition  of: 


Subattribute  "g"  values 

=  "I"  3 
=  "U"  *  23 


Italicized  characters 
Upright,  not  italicized 
characters 
No  change 


m  N 


Subattribute  "h"  values 
=  -F"  51 


Framed 
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=  "C" 
=  "N"  * 


52 
54 


Encircled 

Not  frarried,  not  encircled 
No  change 


■  m 


As  in  B.I 7.3  of  ISO  9040,  *  Indicates  the  value  which  is  the  explicit  modal  default  value  for  the 
subattribute.  Not  all  the  values  of  this  scheme  need  to  have  a  1-1  correspondence  with  emphasis 
levels  available  on  the  real  device.  The  device  object  defines  the  real  mapping. 

When  deteult  values  are  defined  for  a  multiple-occurrence  profile  argument  arxl  fewer  occurrences 
are  negotiated  than  are  required  by  the  value  of  a  parent  VTE-parameter,  the  remaining  occun-ences 
still  take  the  specified  default  values. 

Every  action  corresponding  to  the  operation  of  an  object  updating  device  shall  be  assigned  a  non- 
negative  integer  value.  This  value  shall  be  Interpreted  as  a  logical  l<eystroke  in  accordance  with  the 
definitions  of  the  Sequenced  Terminal  CO  and  Unsequenced  Terminal  CO  in  7.3  and  7.4. 

Values  in  the  range  0-255  are  used  to  generate  entry  of  characters  into  the  Display  Object  from  the 
available  repertoires.  Values  greater  than  255  generate  the  Logical  Keystroi(e  FEE  and  thus  have 
effects  that  are  under  the  control  of  the  FEPCOs  present  in  the  VTE. 

A  minimum  set  of  local  actions  is  defined  within  this  profile,  but  implementors  may  extend  this  as 
required.  A  host  implementation  thus  may  not  l<now  what  local  action  is  being  over-ridden  when 
It  requests  that  a  particular  logical  l<eystroke  should  t>e  notified  to  the  host.  To  prevent  this  from 
limiting  the  capabilities  of  the  terminal,  two  keystroke  combinations  that  differ  only  in  the  inclusion 
or  othen/vise  of  the  ALT  key  are  required  to  have  the  same  potential  local  action.  IHost 
implementations  are  advised  not  to  over-rkle  the  action  of  both  such  keystrokes. 

The  defined  minimum  set  of  local  actions  concerns  control  of  the  current  entry  location.  At  any  time 
when  the  terminal  possesses  the  WAVAR  access  right,  there  is  a  weli-defined  Display  Object  array 
element  which  is  the  current  candidate  for  update  by  a  character  entry  operation,  as  described  in 
Informative  Note  4.  If  this  element  lies  outside  of  any  field,  or  within  a  protected  field,  update  is 
prohibited  unless  the  negotiated  value  of  the  VTE-parameter  access-outside-fields  is  "yes,"  but  the 
array  element  is  still  defined.  Neither  this  location  nor  that  of  any  cursors  which  the  implementation 
may  use  to  Indicate  such  elements  is  recorded  in  the  CCA.  It  is  separate  from  the  current  position 
of  either  the  display  pointer  or  the  logical  pointer,  and  movement  of  this  entry  location  is  a  purely 
local  action. 


55 


PART  14  -  VIRTUAL  TERMINAL  December  1992  (Stable) 


Table  12  -  Local  actions  that  move  entry  location 


Naae 

(Koshifted  Action 

Shifted  Action 

le£t Arrow 

X  =  x-1 

k  =  k-1 

right Arrow 

X  =  x+1 

k  =  k+1 

upArrow 

y  =  y-i 

f  =  f-1,  k  =  1 

downArrow 

y  =  y+i 

f  =  f+1,  k  =  1 

home 

(x,y,z)  =  "start-y" 

(k,f,z)  =  "start-k" 

end 

(x,y,z)  =  "end-y" 

(k,f,z)  =  "end-k" 

pageUp 

z  =  z-1,  x=l,  y=l 

2  =  z~l,  f  =  1,  k  =  1 

PageDown 

z  =  z+1,  x=l,  y=l 

z  =  z+1,  f  =  1,  k  =  1 

tab 

f  =  next(f),  k  =  1 

backTab 

f  -  previous(f),  k  =  1 

The  names  given  in  the  first  column  of  Table  12  are  the  identifiers  of  named  integers  of  type 
STCO.Key.  The  ASN.1  module  STCO  is  defined  as  part  of  the  specification  of  the  Sequenced 
Terminal  Control  Object  in  7.3.  These  identifiers  or  the  corresponding  integers  are  used  to 
designate  the  local  actions  specified  in  the  second  column.  If  the  initial  lower  case  letter  of  such 
a  name  is  converted  to  upper  case  and  prefixed  with  "shift"  then  it  designates  the  local  action 
specified  in  the  third  column. 

In  this  tat}le, " = "  is  used  as  an  assignment  operator.  The  unshifted  actions  reference  array  elements 
by  normal  (x,  y,  z)  coordinates  while  the  shifted  actions  reference  them  by  logical  (k,  f,  z) 
coordinates.  The  values  next(f)  and  previous(f)  are  defined  in  19.1.3.2.2  of  ISO  9040,  "start-k"  and 
"end-k"  are  defined  in  19.1.3.5,  and  "start-y"  and  "end-y"  are  defined  in  19.1.1.4  of  ISO  9040. 

If  the  initial  or  final  coordinate  values  are  undefined  then  the  local  action  is  implementation- 
dependent.  However,  a  host  implementation  can  use  the  mandatory  FEPCO  to  control  the  behavior 
in  such  circumstances.  Field  Entry  Conditions  are  provided  to  test  whether  a  particular  local  action 
would  make  the  entry  location  leave  the  current  field  or  navigation  path,  as  defined  in  8.3.10. 

10.  If  the  VTE-parameter  access-outside-fields  takes  the  value  "allowed,"  when  data  entry  terminates, 
the  display  pointer  shall  be  aligned  with  the  current  entry  location  by  an  explicit  or  implicit 
addressing  operation.  In  this  way,  the  value  of  the  display  pointer  notifies  the  application  of  the 
current  entry  location. 

11.  Use  of  the  values  "F"  (Framed)  and  "C"  (Encircled)  for  emphasis  subattribute  "h"  causes  groups  of 
characters  within  a  single  field  which  have  this  subattribute  value  to  be  outlined  by  a  frame.  The 
two  sut>attributes  differ  only  in  that  the  external  corners  of  the  frame  are  squared  if  value  "P  is  used 
and  rounded  if  value  "C"  is  used.  An  external  corner  is  where  two  lines  meet  in  a  L  shape,  as 
distinct  from  a  T  junction  and  from  the  intersection  of  two  lines.  The  nature  of  the  external  comer 
is  controlled  by  the  subattribute  value  of  the  array  element  on  the  inside  of  the  corner. 
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More  precisely,  a  character  box  element  Is  defined  to  be  within  frame  (f.z)  If  It  Is  In  the  fiekJ  with 
coordinates  (f.z)  and  has  either  the  framed  or  encircled  attribute.  A  character  box  element  Is 
defined  to  be  without  frame  if  either  It  Is  not  In  any  field  or  It  does  not  have  either  the  framed  or 
encircled  attribute.  In  the  image  of  a  y-array  on  the  real  device,  a  line  Is  drawn  between  two 
adjacent  images  of  character  box  elements  If  they  are  within  different  frames,  or  If  one  is  within  a 
frame  and  one  is  without  frame.  In  addition  If  a  character  t>ox  element  is  within  sonr>e  frame,  a  line 
Is  drawn  along  any  edge  of  that  element  which  is  not  in  common  with  any  other  character  box 
element.  I.e..  along  any  edges  which  are  part  of  the  image  of  the  boundary  of  the  Display  Object. 


8.3.15.2       Informative  notes 

1.  Updates  by  the  application  VT-user  (only  possible  within  the  z-window)  are  not  necessarily 
immediately  Imaged  to  the  (human  user  of  the)  terminal  VT-user  unless  the  real  window  of  the 
device  is  currently  positioned  over  such  an  update.  Such  updates  may  move  the  real  window  If  a 
VT-DEUVER  Indication  Is  received. 

When  WAVAR  Is  relinquished  by  the  application  VT-user  the  window  may  be  moved  so  that  the  field 
addressed  by  the  CCO  Is  within  the  window. 

Application  VT-user  addressing  operations  that  advance  z  to  a  higher  address  which  is  outside  of 
the  z-wlndow  cause  the  z-window  to  move  and  Include  one  or  more  new  y-arrays  for  which  no  fields 
are  defined.  As  the  z-wlndow  moves,  one  or  more  y-arrays  at  lower  addresses  will  no  longer  be 
Included  In  the  z-window.  The  field  definition  records  for  such  y-arrays  are  implicitly  deleted. 

2.  Several  of  the  descriptions  of  Field  Entry  Instructions  refer  to  'empty'  array  elements  of  the  Display 
Object.  This  is  to  be  Interpreted  in  the  sense  of  13.2  of  ISO  9040.  Note  that  in  this  sense  an  array 
element  containing  a  space  character  is  not  empty.  The  representation  of  an  empty  array  element 
on  the  real  device  Is  Implementation-dependent,  but  for  this  reason  it  Is  recommended  that  the 
representation  used  should  be  distinct  from  that  of  a  space  character. 

3.  The  descriptions  of  a  number  of  Field  Entry  Conditions  refer  to  the  current  field  and  to  the  current 
location  for  the  next  character  entry.  Typically  this  current  location  will  be  indicated  to  the  human 
user  by  a  visible  cursor.  When  this  location  lies  within  a  defined  field,  that  field  is  the  current  field 
and  the  Entry  Invoke  Character  FEI  may  be  used  to  specify  the  nature  of  the  visible  cursor. 
However,  a  terminal  implementation  may  allow  the  visible  cursor  to  be  moved  outside  of  any  defined 
field.  While  this  is  so,  the  representation  of  the  cursor  is  implementation  dependent,  the  cun-ent  field 
is  undefined  and  no  FEPRs  are  active. 


8.3.16     Specific  conformance  requirements 

For  further  agreement. 
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8.4.1  Introduction 

This  profile  provides  support  for  GCITT  X.3  FAD  compatible  operation. 

The  purpose  of  this  profii®  is  two-fold: 

V  .     a)   to  provide  a  transitional  environment  for  applications  that  assume  the  availability  of  X.3 
parameters  with  which  to  control  the  behavior  of  the  terminal-system; 

b)  to  facilitate  a  gateway  function  between  ISO-WP  and  X.3. 


8.4.2       Association  requirements 


o.H.d.i         runciionai  units 

The  Structured  CO  Fonctional  Unit  is  mandatory. 
The  Urgent  Data  Functiorml  Unit  is  optional. 


8.4.2.2  Mode 

This  Is  an  A-mode  profile. 


8A3       Profile  body 

Display-objects  = 
{ 
{ 

display-object-name  =  D1, 
DO-access  =  profile-argument-r1 , 

dimensions  =  "one", 

x-dimension  ^ 

{ 

x-bound  ^  "unbounded*, 

x-addressing  -  "not-permitted", 

x-absolute  =  "no", 
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x-wlndow      =  0 

}. 

repertoire-assignment  =  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 

}> 

{ 

display-object-name  =  D2, 

DO-access  =  opposite  of  profile-argument-r1, 

dimensions  =  "one", 

x-dimension  = 

{ 

x-bound        =  "unbounded", 
x-addressing  =  "not-permitted", 
x-absolute     =  "no", 
x-window       =  0 

}. 

repertoire-assignment  =  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 

}. 

}, 

Control-objects  = 
{ 

{  *(  PAD  - 

Each  element  of  the  PAD  CO  represents  a  CCITT  PAD  parameter.  The  CO-element-id 

of  each  element  has  been  chosen  so  that  it  would  be  the  same  value  as  the  CCITT  PAD 

parameter  number  that  it  represents.  The  PAD  CO  is  used  both  to  set  CCITT  PAD 

parameter-equivalent  values  and  to  reply  to  an  update  to  the  READ  CO.  See  Definitive 

Note  25  for  conventions  concerning  updates  to  this  CO.  )* 

CO-name      =  PAD, 

CO-structure  =  22, 

co-access     =  "NSAC", 

CO-priority     =  "normal", 

CO-trigger     =  "not-selected", 

{        *(  X.3  parameter  1  -  PAD  recall  )* 

CO-element-id         =  1, 

CO-category  =  "transparent", 

co-size  =  8  }, 

{        *(  X.3  parameter  2  -  PAD  echo  )* 

CO-element-id         =  2, 

CO-category  =  "boolean", 

co-size  =  1  }, 

{        *(  X.3  parameter  3  -  Data  Fonft^arding  Character  )* 
CO-element-id         =  3, 
co-category  =  "boolean", 

co-size  =  7  }, 
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*(  X.3  parameter  4  - 

Idle  Timer  Delay  )* 

CO-element-id 

=  4, 

CO-category 

=  "integer", 

CO°slze 

=  255  }, 

*(  X.3  parameter  5  - 

Ancillary  Device  Control  )* 

CO-element-id 

=  5, 

CO-category 

=  "boolean", 

co-size 

=  1  }. 

*(  X.3  parameter  6  - 

Control  of  PAD  Signals  )* 

CO-element-id 

=  6, 

CO-category 

=  "transparent", 

CO-sIze 

=  4  }, 

*(  X.3  parameter  7  -- 

PAD  action  on  receipt  of  Break  )* 

CO-element-id 

=  7, 

CO-category 

=  "boolean", 

CO-size 

=  5  }, 

*(  X.3  parameter  8  -- 

Discard  Output  )* 

CO-element-id 

=  8, 

CO-category 

=  "boolean", 

CO-size 

=  1  }. 

*(  X.3  parameter  9  - 

Padding  After  <CR>  )* 

CO-element-id 

=  9, 

CO-category 

=  "integer", 

CO-size 

=  7  }, 

*(  X.3  parameter  10 

~  Line  Folding  )* 

CO-element-id 

=  10, 

CO-category 

=  "integer". 

CO-size 

=  255  }, 

*(  X.3  parameter  1 1 

~  Device  Speed  )* 

CO-element-id 

=  11, 

CO-category 

=  "symbolic". 

CO-category 

=  19  }, 

*P(.3  parameter  12  - 

-  Flow  Control  by  Device  )* 

CO-element-id 

=  12, 

CO-category 

=  "boolean", 

CO-size 

=  1  }. 

*(  X.3  parameter  13 

-  Insert  <LF>  after  <CR>  )* 

CO-element-id 

=  13, 

CO-category 

=  "boolean", 

CO-size 

=  3}. 

*(  X.3  parameter  14 

-  Linefeed  Padding  )* 

CO-element-id 

=  14, 

CO-category 

=  "integer", 

CO-size 

=  7}, 

*(X.3  parameter  15 

"  Editing  )* 

CO-element-id 

=  15. 
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• 

co-category  =  "boolean", 

CO-size  =  1  }, 

{       *(  X.3  parameter  16  -  Character  Delete  )* 

CO-element-id         =  16, 

co-category  =  "character", 

CO-repertolre-assignment    *(  any  from  CO  )* 

=  "void",  "void",  <ESC>  2/1  4/0, 

CO-sIze  =  1  }, 

{       *(  X.3  parameter  17  ~  Line  Delete  )* 

CO-element-ld         =  17, 

co-category  =  "character", 

CO-repertolre-asslgnment  *(  any  from  CO  )* 

=  Void",  Void",  <ESC>  2/1  4/0, 

CO-size  =  1  }, 

{       *(  X.3  parameter  18  -  Line  Display  )* 

CO-element-id         =  18, 

co-category  =  "character", 

CO-repertoire-asslgnment  *(  any  from  CO  )* 

=  "void",  "void",  <ESC>  2/1  4/0, 

co-size  =  1  }, 

{        *(  X.3  parameter  19  -  Editing  Sen/ice  Signals  )* 

CO-element-id         =  19, 

CO-category  =  "transparent", 

co-size  =  8  }, 

{        *(  X.3  parameter  20  -  Echo  Mask  )* 

CO-element-id         =  20, 

CO-category  =  "boolean", 

co-size  =  8  }, 

{       *(  X.3  parameter  21  -  Parity  Treatment  )* 

CO-element-id         =  21, 

CO-category  =  "boolean", 

co-size  =  2  }, 

{       *(  X.3  parameter  22  -  Page  Wait  )* 

CO-element-id         =  22, 

CO-category  =  "integer", 

co-size  =  256  } 


{  *(  READ  - 

Each  boolean  of  the  READ  CO  represents  an  element-id  of  the  PAD  CO  with  the  sanr>e 
Identifying  value.  The  READ  CO  is  used  to  request  the  current  values  of  PAD  CO,  which 
may  have  been  changed  by  some  local  agent.  See  the  description  of  the  PAD  CO  for 
how  the  update  to  this  CO  modifies  the  access  to  the  PAD  CO.  )* 
co-name      =  READ, 
CO-structure  =  1, 

CO-access     =  opposite  of  profile-argument-rl , 
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CO-priorlty 

CO-trigger 

CO-category 

CO-size 

}. 


"normal", 
"not-selected", 
"boolean", 
22 


{  *(  Break  Out-of-Band  - 

receipt  of  this  control  object  represents  'X.25  Interrupt";  use  is  applicable  when  boolean 

1  of  element-id  7  in  PAD  CO  has  the  value  true."  )* 

CO-name      =  BO, 

CO-structure  =  1, 

co-access     =  "NSAC", 

CO-priority     =  "urgent", 

CO-trigger     =  "not-selected", 

CO-category  =  "symbolic", 

co-size        =  2 


{  *(  Break  In-Band  - 

receipt  of  this  control  object  represents  "indication  of  break";  use  is  applicable  when 

boolean  3  of  element-id  7  in  PAD  CO  has  the  value  "true."  )* 

CO-name      =  Bl, 

CO-structure  =1, 

co-access     =  "NSAC", 

CO-priority     =  "normal", 

CO-trigger     =  "selected", 

CO-category  =  "symbolic", 

co-size        =  2 


}. 
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{  *(  CUD  - 

This  CO  is  used  to  optionally  convey  Call  User  Data  which  is  normally  carried  in  the 
CCITT  PAD  call.  The  CO  is  not  updatable,  but  rr^ay  be  given  initial  content  value  by 
special  profile  arguments  r2  and  r3.  The  CO  is  parametric,  with  two  elements,  one 
representing  the  protocol  identifier  field,  and  the  other  representing  the  call  data  field 
containing  user  data.  )* 
CO-name      =  CUD, 
CO-structure  =  2, 
CO-access     =  "no-access", 
{       *(  Protocol  Identifier  )* 
CO-element-id  =  1, 
CO-category  =  "character", 
CO-repertoire-assignment  *(  VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size        =  4  }, 
{       *(  User  Data  )* 
CO-element-id  =  2, 
CO-category  =  "character", 
CO-repertoire-assignment  *(\/TS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size        =  124  } 
}. 

{  *(  DTE  - 

This  CO  is  used  to  optionally  indicate  the  calling  and  called  DTE  addresses  which  are 

normally  available  in  a  true  CCITT  PAD  environment.  They  may  not  be  updated,  but  may 

be  given  initial  content  values  by  special  profile  arguments  r4  and  r5.  )* 

CO-name      =  DTE, 

CO-structure  =  2, 

CO-access     =  "no-access", 

{       *(  Calling  DTE  address  )* 

CO-element-id         =  1, 

CO-category  =  "character", 

CO-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 

co-size  =  15  }, 

{       *(  Called  DTE  address  )* 

CO-element-id         =  2, 

CO-category  =  "character", 

CO-repertoire-assignment  *{\/TS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 

CO-size  =  15  } 

}. 
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{  *(  FAC  - 

This  CO  is  used  to  optionally  indicate  the  CCITT  facilities  which  are  normally  negotiable 
during  the  establishment  of  a  PAD  virtual  circuit.  The  negotiation  takes  place  via  special 
profile  argument  r6,  where  the  initiator  may  propose  the  initial  content  value,  and  the 
acceptor  may  return  other  values.  )* 
co-name      =  FAC, 
CO-structure  =  1, 
CO-access     =  "no-access", 
CO-category  =  "character", 
CO-repertoire-assignment  *(\/TS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
CO-size  =127 


Device-objects  *(double  occurrence)*  = 
{ 

{ 

device-name  =  DEVICE-1, 
device-default-CO-access  =  profile-argument-rl , 
device-default-CO-priority  =  "normal", 
device-default-CO-trigger  =  "not-selected", 
device-default-CO-initial-value  =  1."true", 
device-minimum-X-array-length  =  1,*(no  constraint)* 
device-control-object  =  {  Bl,  BO,  PAD  }, 
device-display-object  =  D1 

*(termination  parameters  are  controlled  explicitly  through  the  values  assigned  to  elements 

3  and  4  of  the  PAD  Control  Object)* 

}. 

{ 

device-name  =  DEVICE-2, 

device-default-CO-access  =  opposite  of  profile-argument-rl , 
device-default-CO-priority  =  "normal", 
device-default-CO-trigger  =  "not-selected", 
device-default-CO-initial-value  =  1."true", 
device-minimum-X-array-length  =  1 ,  *(no  constraint)* 
device-control-object  =  {  READ,  PAD  }, 
device-display-object  =  D2 

} 

}. 

Type  of  delivery  control  =  "simple-delivery-control." 
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8.4.4       Profile  arguments 

r1  -  is  mandatory,  and  Is  used  to  establish  the  access  rules  for  the  display  objects  and  several  of  the 
control  objects.  If  the  terminal-system,  I.e.,  that  which  includes  the  equivalent  of  the  PAD  function, 
establishes  the  VTE-proflle  then  the  value  of  r1  should  be  "WACI."  If  the  system  not  including  the 
PAD  function  establishes  the  VTE-proflle  then  the  value  of  r1  should  be  "WACA."  This  argument 
takes  one  of  the  values  "WACI"  or  "WACA."  It  Is  Identified  by  the  identifier  for  DO-access  for  display 
object  D1. 

r2  -  Is  an  optional  special  profile  argument,  and  Is  used  to  set  the  intial  content  value  of  element  1  of 
the  CUD  CO.  The  value  Is  encoded  from  the  binary  form  to  the  ASN.I  type  Printab>leString 
according  to  the  algorithm  described  In  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-1." 

r3  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  element  2  of 
the  CUD  CO.  The  value  Is  encoded  from  the  binary  form  to  the  ASN.I  type  PrintaWeString 
according  to  the  algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-2." 

r4  -  Is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  element  1  of 
the  DTE  CO.  The  value  Is  encoded  from  the  binary  form  to  the  ASN.I  type  PrintaWeString 
according  to  the  algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-3." 

rS  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  element  2  of 
the  DTE  CO.  The  value  Is  encoded  from  the  binary  form  to  the  ASN.I  type  PrintaWeString 
according  to  the  algorithm  described  In  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-4." 

r6  -  Is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  the  FAC  CO. 
The  value  Is  encoded  from  the  binary  form  to  the  ASN.1  type  Printat)leString  according  to  the 
algorithm  described  In  Definitive  Note  24.  This  argument  is  assigned  the  identifier  "Pp-5." 


8.4.5       Profile  notes 


8.4.5.1        Definitive  notes 

1.       The  value  assigned  to  element  1  of  PAD  CO  selects  the  character  used  to  return  control  to  the 
terminal-system.  The  valid  values  and  associated  meanings  are: 
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Table  13  -  PAD  CO  data  element  1  value  definition 


value 

■eaning 

0 

not -permit ted 

1 

1/0  character  (DLE) 

32-126 

graphic  character 

2.  The  value  assigned  to  element  2  of  PAD  CO  determines  whether  or  not  characters  are  echoed  at 
the  terminal-system.  When  the  value  of  this  boolean  is  Irue,'  then  the  characters  are  echoed  at  the 
terminal-system. 

3.  The  values  assigned  to  element  3  of  PAD  CO  control  the  forwarding  of  characters  from  the  terminal- 
system  to  the  application-system  based  on  the  character  value.  The  defined  booleans  and 
associated  meanings  are: 

Table  14  -  PAD  CO  data  element  3  value  definition 


boolean 

■eaning 

1 

alphanimeric  (A-Z,  a-z,  0-9) 

2 

character  0/13  (CR) 

3 

characters  1/11  (ESC),  0/7  (BEL), 
0/5   (ENQ),  0/6  (ACK) 

4 

characters  7/15  (DEL),  1/8  (CAN), 
1/2  (DC2) 

5 

characters  0/3  (ETX),  0/4  (EOT), 

6 

characters  0/9  (HT),  0/10  (LF), 
0/11  (VT),  0/12  (FF) 

7 

all  others  in  coliuan  0  and  1  not 
already  included  above 

4.  The  value  assigned  to  element  4  of  PAD  CO  controls  the  fon/varding  of  characters  from  the  terminal- 
system  to  the  application-system  based  on  the  duration  of  idle  time  elapsed  between  consecutive 
characters  received  by  the  terminal-system  from  the  device.  The  valid  values  include  any  non- 
negative  integer  0-255;  a  value  between  1  and  255  indicates  the  time-out  in  twentieths  of  a  second; 
a  value  of  0  means  that  a  time-out  is  not  a  fonvarding  condition. 

5.  The  value  assigned  to  element  5  of  PAD  CO  determines  whether  the  XON/XOFF  flow-control 
characters  (1  /I  and  1  /3)  are  available  for  use  by  the  terminal-system.  When  the  value  of  this 
element  is  Irue,"  then  the  flow-control  characters  are  available,  and  the  terminal-system  may  use 
them  to  indicate  to  the  device  its  readiness  to  accept  characters  from  it. 

6.  The  value  assigned  to  element  6  of  PAD  CO  determines  whether  the  terminal-system  issues 
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messages,  called  PAD  service  signals,  to  the  device  during  the  association.  The  specific  service 
signals  are  not  a  part  of  this  profile  definition,  only  the  control  of  their  issue. 

7.       The  values  assigned  to  element  7  of  PAD  CO  determine  the  behavior  at  the  terminal-system  when 
a  Break  Is  received  from  the  device.  The  defined  booleans  and  associated  meanings  are: 

Table  15  -  PAD  CO  data  element  7  value  definition 


1  boolean 

■eaning 

1  1 

update  BO  CO 

1  2 

release  the  association 

1  ^ 

update  BI  CO 

1  ^ 

return  control  to  terminal-system 

1  5 

discard  data  from  application-system 

When  all  booleans  have  the  value  lalse,"  there  is  no  action  at  the  terminal-system  when  a  Breal(  is 
received. 

When  boolean  1  is  "true"  and  booleans  3  and  5  are  "false"  and  a  Break  is  received  from  the  device, 
the  terminal  system  updates  the  BO  CO  with  the  symbolic  value  "alone." 

When  booleans  1  and  3  are  "true"  and  boolean  5  is  "false"  and  a  Break  is  received  from 
the  device,  the  terminal  system  updates  the  BO  CO  with  the  symbolic  value  "prepare" 
followed  by  an  update  to  the  BI  CO  with  the  symbolic  value  "unconfirmed." 

When  booleans  1 ,  3  and  5  are  all  "true"  and  a  Break  is  received  from  the  device,  the 
terminal  system  updates  the  BO  CO  with  the  symbolic  value  "prepare"  followed  by  an 
update  to  the  BI  CO  with  the  symbolic  value  "confirmed"  and  discards  all  display  object 
updates  from  the  application  system  until  it  receives  an  update  to  the  PAD  CO  selecting 
element-id  8. 

If  boolean  1  is  "false,"  then  booleans  3  and  5  must  be  "false." 
If  boolean  3  is  "false,"  then  boolean  5  must  be  "false." 


Table  16  -  BI  CO  values  and  semantics 


Syabolic  Value 

Integer  Value 

unconfirmed 

0 

confirmed 

1 
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Table  17  -  BO  CO  values  and  semantics 


f   Syabolic  Value 

Integer  Value 

1  alone 

0 

1  prepare 

1 

8.  The  value  assigned  to  element  8  of  PAD  CO  determines  whether  or  not  the  termined-system  discards 
data  from  the  application-system.  This  element  works  with  element  7  to  acknowledge  the  receipt 
of  the  Break  and  resume  normal  processing  of  display-object  updates.  The  only  valkj  value  of  this 
boolean  In  an  update  is  "false." 

9.  The  value  assigned  to  element  9  of  PAD  CO  indicates  the  number  of  padding  characters  to  be 
generated  by  the  terminal-system  to  the  device  following  a  carriage  retum  character.  The  valkJ 
values  are  integers  in  the  range  0-7. 

10.  The  value  assigned  to  element  10  of  PAD  CO  indicates  the  number  of  graphic  characters  sent  to 
the  device  after  which  the  terminal-system  will  insert  a  carriage  return.  The  valid  values  are  integers 
In  the  range  0-255,  where  a  value  of  0  means  that  this  function  is  not  performed. 

1 1 .  The  value  assigned  to  element  1 1  of  PAD  CO  indicates  the  bit-transmission  speed  of  the  device. 
This  element  may  only  appear  in  an  update  sent  to  the  application-system  in  response  to  an  update 
of  the  READ  CO  when  boolean  1 1  has  the  value  "true." 

12.  The  value  assigned  to  element  12  of  PAD  CO  determines  whether  the  XON/XOFF  flow-control 
characters  (1  /I  and  1  /3)  are  available  for  use  by  the  device.  When  the  value  of  this  element  Is 
"true,"  then  the  flow-control  characters  are  available,  and  the  device  may  use  them  to  indicate  to  the 
terminal-system  its  readiness  to  accept  characters  from  it. 

13.  The  values  assigned  to  element  13  of  PAD  CO  determine  under  which  situations  a  linefeed  is 
Inserted  following  a  carriage  return  character.  The  valid  values  and  associated  meanings  are: 


Table  18  -  PAD  CO  data  element  13  value  definition 


boolean 

■eaning 

1 

insert  linefeed  after  carriage 
return  sent  to  device 

2 

insert  linefeed  after  carriage 
return  received  from  device 

3 

insert  linefeed  after  carriage 
return  echoed  to  the  device 

14.     The  values  assigned  to  element  14  of  PAD  CO  determine  the  number  of  padding  characters 
generated  by  the  terminal-system  to  the  device  following  a  linefeed  character.  The  valid  values  are 
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any  number  in  the  range  0-7. 

15.  The  value  assigned  to  element  15  of  PAD  CO  determines  whether  or  not  the  terminal-system 
performs  data-editing.  When  this  CO  has  value  "true,"  the  values  of  the  elements  3  and  4  of  the 
PAD  CO  are  ignored. 

1 6.  The  value  assigned  to  element  1 6  of  PAD  CO  determines  which  character  is  used  In  editing  the  line 
to  signify  the  function  "delete  character."  The  valid  values  are  the  IA5  characters,  decimal  value  0- 
127.  Only  applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

17.  The  value  assigned  to  element  17  of  PAD  CO  determines  which  character  is  used  In  editing  to 
signify  the  function  "delete  line."  The  valid  values  are  the  IA5  characters,  decimal  value  0-127.  Only 
applicable  If  the  value  of  element  15  of  PAD  CO  is  "true." 

18.  The  value  assigned  to  element  18  of  PAD  CO  determines  which  character  is  used  in  editing  to 
signify  the  function  "display  line."  The  valid  values  are  the  IA5  characters,  decimal  value  0-127.  Only 
applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

19.  The  value  assigned  to  element  19  of  PAD  CO  determines  whether  the  terminal-system  provides  for 
editing  of  PAD  service  signals.  The  valid  values  and  meanings  are  as  follows: 

Table  19  -  PAD  CO  data  element  19  value  definitions 


value 

meaning 

0 

no  editing 

1 

editing  as  for  a  paper  device 

2 

editing  as  for  a  glass  device 

8 

editing  using  one  editing  character 

32-126 

editing  using  one  editing  character 

20.  The  values  assigned  to  element  20  of  PAD  CO  determines  which  characters  are  NOT  to  be  echoed 
to  the  device  by  the  terminal-system,  if  no  bits  are  set,  then  all  characters  are  to  be  echoed, 
assuming  that  element  2  has  the  value  "true."  The  defined  booleans  and  associated  meanings  are: 
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Table  20  -  PAD  CO  data  eiemsnt  20  value  definition 


1  

1  boolean 

Beaning 

Do  not  echo  0/13  (CR) 

2 

Do  not  echo  0/10  (LF) 

3 

Do  not  echo  0/11  (VT),  0/9  (HT),  0/12  (FF) 



Do  not  echo  0/7  (BEL),  0/8  (BS) 

5 

Do  not  echo  l/ll  (ESC),  0/5  (ENQ) 

6 

Do  not  echo  0/6  (ACK),  1/5  (NAK),  0/2  (STX), 
0/1  (SOH),   0/4   (EOT),  1/7  (ETB),   0/3  (ETX) 

7 

Do  not  echo  the  editing  characters  defined  by 
data  elements  16,  17,  and  18  of  the  PAD  CO 

8 

Do  not  echo  7/15  (DEL)  or  any  of  the  other 
characters  belonging  to  CO  or  CI  which  are 
not  already  mentioned  above 

21 .      The  value  assigned  to  element  21  of  PAD  CO  determines  the  treatment  of  parity  on  the  characters 
received  from  and  sent  to  the  device  from  the  terminal-system.   The  defined  booleans  and 

associate  meanings  are: 

Table  21  -  PAD  CO  data  element  21  value  definition 


1  boolean 

meaning 

1 

parity  is  checked  on  characters  received  from  the 
device 

parity  is  generated  on  characters  sent  to  the 
device 

22.  The  value  assigned  to  element  22  of  PAD  CO  determines  the  number  of  linefeeds  that  the  terminal- 
system  may  send  to  the  device  before  it  must  wait  for  input  from  the  device  to  request  It  to  continue 
displaying  characters.  The  range  of  valid  values  is  0-255,  where  a  value  of  0  indicates  that  the 
terminal-system  need  never  wait. 

23.  The  TEXT  operation  is  the  only  operation  allowed  on  the  display  objects. 

24.  Special  profile  arguments  r2-r6  have  binary  values.  However,  due  to  a  restriction  in  the  standards 
9040  and  9041,  those  binary  values  must  be  conveyed  in  the  ASN.1  type  PrintableString.  This  Is 
accomplished  by  mapping  the  value  of  each  semi-octet  in  the  string  of  binary  octets  to  an  octet 
whose  value  falls  In  the  value  range  of  a  PrintableString.  The  semi-octet  values  in  the  range  0000  - 
1001  are  mapped  into  the  PrintableString  values  '0'  -  '9',  whereas  the  semi-octet  values  in  the  range 
1010  - 1 1 1 1  are  mapped  into  the  PrintableString  values  'A'  -  'F'.  The  result  is  a  string  of  characters 
which  is  exactly  twice  the  length  of  the  original  string  of  binary  octets. 
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25.  The  value  of  CO-access  for  the  PAD  CO  Is  "NSAC,"  however  a  convention  is  follawed  that 
determines  when  a  VT-user  may  update  the  PAD  CO.  Only  the  VT-user  with  access  to  the  Display 
Object  D2  may  update  the  PAD  CO  except  immediately  after  it  has  updated  the  READ  CO.  When 
the  READ  CO  update  is  received  by  the  opposite  VT-user,  it  is  treated  as  a  request  to  update  the 
PAD  CO  with  the  parameter  values  it  is  currently  using,  at  which  point  that  VT-user  is  required  to 
respond. 

26.  The  application  system  can  update  the  Bl  CO  and  the  terminal  system  shall  send  a  Break  to  the 
device.  If  the  symbolic  value  of  the  update  is  "confirmed,"  the  terminal  system  shall  respond  with 
an  update  to  the  PAD  CO  selecting  element-id  8. 


8.4.5.2        Informative  notes 

1.  Users  of  this  profile  should  refer  to  CCITT  Recommendations  X.3,  X.28  and  X.29  for  the  original 
model  for  this  profile. 

2.  The  following  values  for  the  elements  of  the  PAD  CO  are  taken  from  the  CCITT  Simple  standard 
profile  and  may  prove  useful: 
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data  eleaent 

value 

■eaning 

1 

1 

possible  to  return  control  to 
terminal-system  using  0/1  (DLE) 

2 

1. "true* 

echo  performed  at  the  terminal-system 

3 

1.  "false" , 

2.  "true",  3. "true", 
4. "true",  5. "true", 
6. "true",  7. "true" 

forward  on  receipt  of  any  character  in 
CO  and  CI 

4 

0 

no  time-out  used  for  forwarding 
condition 

5 

l,"true" 

terminal-system  may  use  XON/XOFF  to 
flow-control  the  device 

6 

1. "true" 

service  signals  are  sent 

7 

2. "true",  all 
others  "false" 

release  the  association  when  a  Break 
is  received  from  the  device 

8 

1. "false" 

deliver  data  to  device  | 

9 

0 

do  not  pad  after  CR 
—  ^  —  —  ___ 

10 

0 

do  not  fold  the  line 

11 

read-only 

12 

1. "true" 

device  may  use  XON/XOFF  to  flow- 
control  the  terminal-system 

13 

0 

do  not  insert  LF  after  CR 

14 

0 

do  not  pad  after  LF 

15 

1. "false" 

do  not  edit  data 

16 

7/15  (DEL) 

character  delete 

17 

1/8  (CAN) 

line  delete 

18 

1/2  (DC2) 

line  display 

19 

1 

edit  as  for  paper 

20 

0 

echo  all  characters 

21 

0 

no  parity  checking  or  generation 

22 

0 

no  page  wait  | 

3.       The  following  values  for  the  elements  of  the  PAD  CO  are  taken  from  the  CCITT  Transparent  standard 
profile  and  may  prove  useful. 
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data  •l«m«nt 

valu* 

meaning 

1 

0 

control  may  not  be  returned  to  the  terminal-Bystefn 

2 

1. "false" 

terminal-system  does  not  perform  character  echo 

3 

all  booleans  'false' 

no  fonwarding  on  character  value 

4 

20 

forward  on  time-out  of  1  second 

1  ^ 

1. 'false' 

terminal-system  may  not  flow-control  the  device 

le 

1. "false" 

service  signaUs  are  never  sent 

1  7 

2.true'.  all  others  "false" 

release  the  association  when  a  Break  is  received  from  tf>e 

8 

•J /false' 

riAlii/Ar  c\tAtk  to  HfkMiC^ 

UwllVOI    VIOICI  IW  VJWI\^V 

Q 

0 

f\r\  not  nsH  sftAr  r^R 

\Jk\J  1  IWl  IJOU  ClliOl  Wffl 

in 

n 

Ho  not  folH  thA  linA 

1  l\J\  i\Jl\J  II       III  lO 

11 

12 

1  .'false' 

device  may  not  flow-control  the  terminal-system 

13 

0 

do  not  insert  LF  after  CR 

14 

0 

do  not  pad  after  LF 

15 

1. 'false' 

do  not  edit  data 

16 

7/15  (DEL) 

character  delete 

17 

1/8  (CAN) 

line  delete 

18 

1/2  (DC2) 

line  display 

19 

1 

edit  as  for  paper 

20 

0 

echo  all  characters 

21 

0 

no  parity  checking  or  generation 

22 

0 

no  page  wait 

8.4.6       Specific  conformance  requirements 

None. 
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OIW  VTE-Profile  Generalized  Telnet-1991  (r1,r2) 


8.5.1  Introduction 

This  proffle  provides  support  for  TEUMET-lilce  operation  for  users  of  thie  iSO  Virtual  Terminal  Service.  It  is 
based  on  tlie  IS  version  of  ISO  9040  and  ISO  9041.  This  profile  references  the  ARPA  internet  TEUSIET 
standards  docunients  for  the  seniantics  of  option  negotiation  and  the  values  of  symtx)lic  constants. 


8.5.2       Association  requirements 

8.5.2.1  Functional  units 

The  Structured  Control  Objects  Functional  Unit  Is  required.  The  Urgent  Data  Functional  Unit  is  optional,  but 
should  be  used  whenever  available. 

8.5.2.2  Mode 

This  is  an  A-mode  profile. 


8.5.3      Profile  body 


Display-objects  =  *(double  occurrence)* 
{ 

{ 

display-object-name  =  D,  *(DISPLAY)* 

do-access  =  "WACA", 

dimensions  =  two", 

x-dlmension  = 

{ 

x-bound 
x-addressing 
x-absolute 
x-window 


y-dimension  = 
{ 

y-bound 

y-addressing 

y-absolute 


"unbounded", 
"no  constraint", 

"yes",  *(See  Definitive  Note  5)^ 
profile-argument-r1 


"unbounded", 
"higher  only", 
no , 


74 


PART  14  -  VIRTUAL  TERMINAL 


December  1992  (Stable) 


y-wlndow       =  1 

}. 

erasure-capability      =  '^es', 
repertoire-capability   =  *(implicitly  defined  by  r2)*, 
repertoire-assignment         =  profile-argument-r2, 
repertoire-assignment         =  <ESC>  2/5  2/15  4/2 
}. 
{ 

display-object-name  =  K,  *(KEYBOARD)* 
do-access  =  "WACI", 

dimensions  =  "two", 

x-dimension  = 

{ 

x-bound  =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute  =  "yes",        *(See  Definitive  Note  5)* 

x-window  =  profile-argument-rl 

}. 

y-dimension  = 
{ 

y-bound  =  "unbounded", 

y-addressing  =  "higher  only", 

y-absolute  =  "no", 

y-window  =  1 

}. 

erasure-capability     =  "yes", 
repertoire-capability  =  *(implicitly  defined  by  r2)*, 

repertoire-assignment  =  profile-argument-r2, 

repertoire-assignment  =  <  ESC  >  2/5  2/15  4/2 

}. 

}. 

Control-objects  =  *(multiple  occurrence)* 
{ 

{  *(SYNCHRONIZE)* 

co-name      =  SY, 
CO-category  =  "symbolic", 
co-access     =  "NSAC", 
co-size        =  1, 
CO-priority     =  "urgent" 

}. 

{  *(DISPLAY-SIGNAL)* 

co-name      =  Dl, 
CO-category  =  "symbolic", 
CO-size        =  255, 
co-access     =  "WACA", 
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CO-priorlty     =  "normal", 
CO-trlgger     =  "selected" 

}. 

{•(KEYBOARD-SIGNAL)* 
CO-name      =  KB, 
co-category  =  "symbolic", 
co-size        =  255, 
co-access     =  "WACI", 
CO-priority     =  "normal", 
co-trigger     =  "selected" 

}. 

{  *(NEGOTIATION  BY  INITIATOR)* 
co-name      =  Nl, 
CO-structure    =  2, 

*(D0/D0N7)* 

CO-element-id  =1, 

CO-category     =  "boolean", 

co-size        =  256, 

*(WILL/WONT)* 

CO-element-id   =  2, 

co-category     =  "boolean", 

co-size        =  256, 
co-access     =  "WACI", 
CO-priority     =  "normal", 
CO-trigger     =  "selected" 

}. 

{  *(NEGOTIATION  BY  ACCEPTOR)* 
co-name      =  NA, 
CO-structure    =  2, 

*(DO/DONT)* 

CO-element-id  =1, 

CO-category     =  "boolean", 

co-size         =  256, 

*(WILL/WON"n* 

CO-element-id   =  2, 

CO-category     =  "boolean", 

co-size         =  256, 
co-access     =  "WACA", 
CO-priority     =  "normal", 
co-trigger     =  "selected" 

}. 

{  *(SUBNEGOTIATION  BY  INITIATOR)* 
CO-name      =  SBI, 
CO-structure    =  2, 

*(TELNET  OPTION)* 

CO-element-id  =1, 
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co-category     =  "symbolic", 

co-size        =  256, 

*(SUBNEGOTIATION)* 

CO-element-id   =  2, 

co-category     =  "character", 

CO-repertoire-assignment  =  <ESC>  2/5  2/15  4/2, 

*(Virtual  Terminal  Service  Transparent  Set)* 

co-size        =  1024, 
co-access     =  "WACI". 
CO-priority     =  "normal", 
CO-trigger     =  "selected" 

}. 

{  *(SUBNEGOTIATION  BY  ACCEPTOR)* 
CO-name      =  SBA, 
CO-structure    =  2, 

*(TELNET  OPTION)* 

CO-element-id   =  1, 

CO-category     =  "symbolic", 

CO-size        =  256, 

*(SUBNEGOTIATION)* 

CO-element-id   =  2, 

CO-category     =  "character", 

CO-repertoire-assignment  =  <ESC>  2/5  2/15  4/2, 

*  (Virtual  Terminal  Sen^ice  Transparent  Set)* 

CO-size        =  1024, 
co-access     =  "WACA", 
CO-priority     =  "normal", 
CO-trigger     =  "selected" 

}. 

Device-objects  =  *  (double  occurrence)* 
{ 

{ 

device-name  =  DISPLAY-DEVICE. 

device-display-object  =  D, 

device-default-CO-initial-value        =  1."true",*(on)* 

device-minimum-X-array-length       =  1,*(no  constraint)* 

device-minimum- Y-array-length       =  1,* (no  constraint)* 

device-control-object  =  SY, 

device-control-object  =  NA, 

device-control-object  =  Dl, 

device-control-object  =  SBA, 

*(SYNC,  NEGOTIATE-ACCEPTOR, 
DISPLAY-SIGNAL,  SUBNEGOTIATE-ACCEPTOR)* 

device-default-CO-access     =  "WACA", 

device-default-CO-priority     =  "normal" 
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*  (other  device  object  parameters  assume  corresponding 

DO  values)* 

}. 

{ 

device-name  =  KEYBOARD-DEVICE, 

device-display-object  =  K, 

device-default-CO-initial-value        =  1  ."true",*(on)* 
device-minimum-X-array-length       =  1,* (no  constraint)* 
device-minimum-Y-array-length       =  1,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  Nl, 
device-control-object  =  KB, 
device-control-object  =  SBI, 

*(SYNC,  NEGOTIATE-INITIATOR. 

KEYBOARD-SIGNAL,  SUBNEGOTIATE-INITIATOR)* 
device-default-CO-access     =  "WACI", 
device-default-CO-priority     =  "normal" 
*(other  device  object  parameters  assume  corresponding 
DO  values)* 
} 

Type  of  delivery  control  =  "simple-delivery-control." 


8.5.4       Profile  argument  definitions 

r1  -  Is  used  to  represent  the  line  length  as  the  value  of  VTE  parameter  x-wlndow  for  both  display 
objects.  This  argument  Is  mandatory  and  takes  a  nonnegative  integer  value.  This  argument  is 
identified  by  the  identifier  for  x-window  for  display  object  D. 

r2  -  is  used  to  designate  the  repertoires  for  both  display  objects.  This  argument  is  optional,  and  may 
occur  a  number  of  times  in  an  ordered  list  to  provide  for  negotiation  of  values  for  the  VTE-parameter 
repertoire-assignment.  The  value  for  the  VTE-parameter  repertoire-capability  is  implied  by  the 
number  of  occurrences  of  this  profile  argument.  The  VTE-parameter  repertoire-capability  equals  the 
number  of  occurrences  of  this  profile  argument  plus  one.  The  default  is  a  single  occurrence  of  the 
value  designating  the  full  U.S.  ASCII  set.  This  argument  is  identified  by  the  identifier  for  repertoire 
assignment  for  display  object  D. 


8.5.5       Profile  dependent  CO  Information 
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8.5.6.1        Definitive  notes 


1.  Sending  a  KB  or  Dl  control  object  update  is  the  equivalent  of  sending  a  TELNET  'lAC 
<  command  > "  sequence.  The  symbolic  value  in  the  KB  or  Dl  control  object  update  Is  equal 
to  the  TELNET  command  code  as  specified  in  the  TELNET  Assigned  Numbers. 

The  following  values  must  be  recognized: 


SYMBOLIC 

NAME 

VALUE 

Dl^ 

Data  Mark 

242 

BRK 

Break 

243 

IP 

Interrupt  Process 

244 

AO 

Abort  output 

245 

AYT 

Are  You  There 

GA 

Go  ahead 

249 

The  following  values,  corresponding  to  TELNET  commands,  are  excluded  from  KB  and  Dl 
control  object  updates: 


SYMBOLIC 

NAME 

VALUE 

SE 

End  Subnegotiation 

240 

EC 

Erase  character 

EL 

Erase  Line 

248 

SB 

Subnegotiation 

WILL 

Will 

251 

WONT 

Won't 

252 

DO 

Do 

253 

DONT 

Don't 

254 

lAC 

Escaped  lAC 

255 

The  Nl  and  NA  control  objects  are  used  in  place  of  the  DO,  DONT,  WILL,  WONT 
commands. 

The  SBI  and  SBA  control  objects  are  used  in  place  of  the  SB  <suboptions>  SE 
command  sequence. 

The  EC  and  EL  commands  are  replaced  by  display  object  updates. 

The  lAC  is  not  needed  because  commands  are  not  embedded  in  the  text. 
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The  recognition  of  values  corresponding  to  TELNET  commands  defined  in  a  TELNET 
option  will  be  dependent  upon  the  successful  negotiation  of  the  TELNET  option  that  defines 
the  additional  TELNET  command.  Unrecognized  values  shall  be  ignored. 

2.  The  equivalent  of  a  TELNET  SYNCH  command  is  achieved  by  updating  the  SY  control 
object  with  the  single  symbolic  value  of  "SYNCH"  (which  is  mapped  onto  the  integer  value 
1),  and  immediately  updating  the  Dl  (or  KB)  control  object  with  symbolic  value  DM.  When 
an  update  to  the  SY  control  object  is  received  subsequent  display  object  updates  are 
discarded  until  an  update  to  the  Dl  or  KB  control  is  received  with  symbolic  value  DM.  If  a 
VT-BREAK  is  received  after  an  SY  CO  update  has  been  received  and  prior  to  the 
corresponding  Dl  or  KB  CO  update  with  symbolic  value  of  DM,  the  discarding  of  updates 
is  terminated.  This  is  necessary  because  the  VT-BREAK  may  have  caused  the  Dl  or  KB  CO 
update  to  be  purged. 

3.  The  Nl  and  NA  control  objects  are  used  to  emulate  the  TELNET  option  negotiation  facility. 
The  facility  is  symmetric,  allowing  either  party  to  open  negotiation  for  a  change  of  mode, 
and  every  negotiation  must  be  accepted  or  rejected  by  the  opposite  party.  The  rules  for 
negotiation  for  each  of  the  option  controls  are  as  stated  in  the  TELNET  specification  and 
as  given  below: 

a.  Only  open  negotiation  for  a  change  from  the  current  state; 

b.  Only  acknowledge  negotiation  for  a  change  from  the  current  state; 

Nl  and  NA  are  structured  control  objects  consisting  of  two  boolean  data  elements.  For  full 
symmetry,  both  N I  and  N A  have  the  same  value  definitions.  The  first  boolean  data  element 
stands  for  DO/DONT  and  the  second  boolean  data  element  stands  for  WILL/WONT.  The 
ordinal  position  of  the  boolean  value  in  the  data  element  corresponds  to  the  TELNET  option 
number  plus  one.  This  allows  the  ordinal  position  of  bits  1-256  in  the  boolean  object  to 
represent  the  TELNET  options  values  of  0-255.  DO  is  represented  as  a  "true"  boolean  value 
in  CO-element-id  1 .  DONT  is  represented  as  a  "false"  boolean  value  in  CO-element-id  1 . 
WILL  is  represented  as  a  "true"  boolean  value  in  CO-element-id  2.  WONT  is  represented 
as  a  "false"  boolean  value  in  CO-element-id  2. 

4.  The  SBI  and  SBA  control  objects  provide  subnegotiation  for  TELNET  options,  and 
correspond  to  the  TELNET  command  sequence  "I AC  SB  < TELNET  option  code> 
<  subnegotiation  >  I  AC  SE".  Element  id  1  contains  the  TELNET  option  code,  and  element 
id  2  contains  the  octets  that  comprise  the  subnegotiation.  The  specification  for  the  TELNET 
option  defines  the  semantics  of  the  value  in  element  id  2. 

5.  The  TELNET  EC  (erase  character)  command  will  be  mapped  to  a  pointer  relative  (x:  =  x-1) 
update  and  an  erase  current  update.  This  is  the  only  instance  when  backward  explicit 
addressing  is  permitted. 

The  TELNET  EL  (erase  line)  command  will  be  mapped  to  an  erase-full-x-array  update  (an  erase 
operation  where  the  extent  is  defined  as  <  "start-x,"Yc,Xc-l )  >  and  a  pointerupdate  to  set  x  =  1 .  This 
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Is  the  only  Instance  when  absolute  explicit  addressing  Is  pemnltted. 

6.  The  X  address  of  the  pointer  can  be  moved  forward  only  by  Implicit  pointer  addressing. 
Addressing  of  the  Y  dimension  is  limited  to  the  next  X-array  update  operation. 

7.  The  VT  next  X-array  update  operation  will  be  sent  in  place  of  the  TELNET  NVT  "CR,  LP 
sequence. 

8.  When  a  party  wants  to  change  the  repertoire  assignment  for  the  display  object  to  which  it 
has  access,  it  does  so  by  issuing  an  update  to  the  modal  value  for  the  character  repertoire 
attribute.  It  should  be  noted  that  no  mechanism  exists  for  a  party  to  request  a  change  of 
repertoire  assignment  for  the  display  object  to  which  it  does  not  have  access.  In  the 
specific  case  of  the  TCP/IP  TELNET  binary  option,  you  must  first  complete  a  successful 
TELNET  negotiation  to  do  so.  Then  the  party  with  the  access  rights  to  the  display  object 
in  question  is  required  to  perform  the  secondary  attribute  modal  update.  If  a  negotiation 
to  change  the  "binary"  repertoire  is  refused,  the  current  repertoire  will  remain  in  effect. 
When  a  negotiation  to  quit  using  the  "binary"  repertoire  succeeds,  the  party  with  the  access 
rights  to  the  display  object  in  question  is  required  to  perform  the  corresponding  secondary 
attribute  modal  update  to  switch  to  the  explicit  modal  default  value. 

9.  While  the  "binary"  repertoire  is  being  used  no  mapping  to  the  pointer  addressing  or  erase 
operations  will  be  done. 

10.  The  repertoire  designation  "7-bit  ASCII  (GO+CO)"  refers  to  the  repertoire  invoked  by  ISO 
2022  defined  character  set  designating  escape  sequences  <ESC>  2/8  4/2,  "void," 
<  ESC>  2/1  4/0.  The  repertoire  designation  "7-bit  ASCII  (GO  only)"  refers  to  the  repertoire 
invoked  by  ISO  2022  defined  character  set  designating  escape  sequences  <ESC>  2/8 
4/2.  The  designation  "binary"  refers  to  the  "Virtual  Terminal  Service  Transparent  Set" 
registered  in  the  International  Register  under  ISO  2375  register  value  125  and  invoked  by 
the  escape  sequence  <ESC>  2/5  2/15  4/2. 

11.  No  termination  event  list  is  specified  so  that  data  buffering  and  delivery  can  be  controlled 
according  to  context.  If  local  echoing  is  enabled,  the  local  newline  or  other  event  shall 
trigger  a  VT-DELIVER  request.  With  remote  echo  a  timeout  or  buffer  length  may  be  used 
to  trigger  a  VT-DELIVER  request.  This  buffer  length  may  be  1 . 

8.5.6.2        Informative  notes 

1 .       Users  of  this  profile  should  refer  to  the  TELNET  specification  (MIL-STD-1 782)  and  RFCs: 

854  Protocol  Specification 

855  Options  Specification 

or  their  successors  for  semantics  of  the  TELNET  commands.  These  documents  can  be 
obtained  by  contacting  SRI  International,  DDN  Network  Information  Center,  333 
Ravenswood  Ave.,  Menio  Park,  CA  94025,  (41 5)  859-3695. 
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2.  This  profile  is  derived  from  the  Telnet-1 988  profile.  The  negotiation  control  objects,  NA  and 
Nl,  have  been  changed  to  model  the  DO/CX)NT  WILL/WONT  negotiation  of  TELNET 
options.  The  size  of  the  elements  of  the  NA  and  Nl  negotiation  control  objects  equals  the 
range  of  TELNET  option  numbers,  including  the  numbers  presently  assigned  and  those 
reserved  for  future  options.  An  implementation  can  refuse  options  that  it  doesn't  support. 
This  allows  implementations  to  maintain  interoperability  while  new  TELNET  options  are 
incorporated.  The  CO-category  of  the  KB  and  Dl  control  objects  have  been  changed  from 
"boolean"  to  'symbolic'  A  'Go-Ahead'  will  be  signaled  by  a  control  object  update  to  the 
Dl  or  KB  control  object  with  symbolic  value  of  GA;  therefore,  the  OA  control  object  has  been 
dropped. 

3.  If  the  'go  ahead"  facility  has  been  negotiated  then  following  a  VT-BREAK,  only  the 
association  acceptor  has  the  right  to  send  data.  VT-BREAK  causes  all  negotiated  TELNET 
option  values  to  be  reset  to  their  initial  values.  If  negotiated  values  are  to  be  restored,  they 
must  be  renegotiated. 

4.  It  is  recognized  that  some  implementations  may  have  character  set  repertoire  requirements 
that  are  currently  outside  the  scope  of  TCP/IP  TELNET.  Implementations  such  as 
Gateways  that  require  access  to  these  facilities  via  non-standard  extensions  to  TCP/IP 
TELNET  will  be  able  to  maintain  conformance  with  VT  by  utilizing  profile  argument  R2  and 
mapping  in  both  directions  between  repertoire  change  requests  and  appropriate  modal 
attribute  updates. 

8.5.7       Specific  conformance  requirements 

The  following  character  sets  are  required: 

^     -       The  GO  character  set  for  U.S.  ASCII  (values  32-126); 
The  full  U.S.  7-bit  ASCII  (values  0-127); 
}        -        The  transparent  character  set,  see  Definitive  Note  8  in  section  1 4.8.5.6.1 . 
Negotiation  to  Suppress  GoAhead  must  be  accepted. 
8.6     S-mode  paged  application  profile 

See  PDISP 11187-2  (AVT-23  S-mode  Paged  Application  Profile). 
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Annex  A  (normative)  

Specific  ASE  requirements 

For  spedflc  ASE  Requirements  identified  by  the  Upper  Layer  SIG  for  Virtual  Termiruils,  see  Stable 
Implementation  Agreements  for  Open  Systems  Interconnection  Protocols:  Part  5  -  Upper  Layers. 


! 
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Annex  B  (normative)  

Clarifications 

Qflfiyllft 

When  a  proMe  argument  is  not  present  in  either  the  offer  or  value  list,  the  defoult  for  the  corresponding  VTE 
parameter  is  specified  by  ISO  9040  if  it  is  not  given  by  the  argument  description  in  the  profile. 
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Annex  C  (normative)  

Object  identifiers 

General  Identifiers: 

olw-vt  OBJECT  IDENTIFIER ::  = 

{ lso(1)  identlfiecl-organlzation(3)  oiw(14)  vtslg(12)  } 

oiw-vt-pr  OBJECT  IDENTIFIER ::  = 

{  oiw-vt  vteProfile(l) } 

Olw-vt-co  OBJECT  IDENTIFIER  ::  - 

{  oiw-vt  controlObject(0) } 

oiw-vt-co-misc         OBJECT  IDENTIFIER ::  = 
{  oiw-vt-co     cotypemisc(0) } 

oiw-vt-co-tcco  OBJECT  IDENTIFIER  ::  = 
{  oiw-vt-co     cotypetcco(4) } 

Profiles  defined  by  OIW  VT  SIG: 

oiw.vt-pr-telnet-1988  OBJECT  IDENTIFIER ::  = 

{oiw-vt-pr     telnet-1 988(0)  } 

oiw-vt-pr-transparent-1988    OBJECT  IDENTIFIER ::  = 
{  oiw-vt-pr     transparent-1 988(1)  } 

oiw-vt-pr-forms-1989  OBJECT  IDENTIFIER ::  = 

{  oiw-vt-pr     forms-1 989(2)  } 

oiw-vt-pr-x3-1989  OBJECT  IDENTIFIER ::  = 

{  oiw-vt-pr     x3-1 989(4)  } 

oiw-vt-pr-generalizedTelnet  OBJECT  IDENTIFIER  ::  = 
{  oiw-vt-pr     generalizedTelnet(5) } 

Control  Objects  defined  by  OIW  VT  SIG: 

oiw-vt-co-misc-sa  OBJECT  IDENTIFIER  ::  - 

{  oiw-vt-co-misc       sa(0) } 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co-misc       ua(1)  } 
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olw-vt-co-mlsc-st  OBJECT  IDENTIFIER  •  = 

{  olw-vt-co-misc  st(2) } 

olw-vt-co-mlsc-ut  OBJECT  IDENTIFIER  = 

{  oiw-vt-co-misc  ut(3) } 
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